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IAX: Inter-Asterisk eXchange Version 2 
Abstract 


This document describes IAX, the Inter-Asterisk eXchange protocol, an 
application-layer control and media protocol for creating, modifying, 
and terminating multimedia sessions over Internet Protocol (IP) 
networks.  IAX was developed by the open source community for the 
Asterisk Private Branch Exchange (PBX) and is targeted primarily at 
Voice over Internet Protocol (VoIP) call control, but it can be used 
with streaming video or any other type of multimedia. 


IAX is an "all in one" protocol for handling multimedia in IP 
networks. It combines both control and media services in the same 
protocol. In addition, IAX uses a single UDP data stream on a static 
port greatly simplifying Network Address Translation (NAT) gateway 
traversal, eliminating the need for other protocols to work around 


NAT, and simplifying network and firewall management.  IAX employs a 
compact encoding that decreases bandwidth usage and is well suited 
for Internet telephony service. In addition, its open nature permits 


new payload type additions needed to support additional services. 
Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 
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Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5456. 


IESG Note 


This RFC is not a candidate for any level of Internet Standard. The 
IETF disclaims any knowledge of the fitness of this RFC for any 
purpose and in particular notes that the decision to publish is not 
based on IETF review for such things as security, congestion control, 
or inappropriate interaction with deployed protocols. The RFC Editor 
has chosen to publish this document at its discretion. Readers of 
this document should exercise caution in evaluating its value for 
implementation and deployment. See RFC 3932 for more information. 


The IESG thinks that this work is related to IETF work done in SIP, 
MMUSIC, and AVT WGs, but this does not prevent publishing. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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Introduction 


Numerous protocols have been specified by the Internet community to 
support control or signaling of multimedia sessions, for instance, 
SIP [RFC3261], Media Gateway Control Protocol (MGCP) [RFC3435], and 
MEGACO/H.248 [RFC3525] (which has been obsoleted and made historic by 
[RFC5125]). In general, these protocols are designed to offer full 
support for many types of media transmission. This flexible approach 
adds some overhead to the protocol headers, but allows for the 
protocol use well beyond the current application. Typically, these 
protocols reference, but do not specify, the media transmission 
protocol used to carry the actual stream. SIP commonly uses Session 
Description Protocol (SDP) [RFC4566] to specify Real-Time Transport 
Protocol (RTP) [RFC3550] streams. This method allows for great 
flexibility, but again leads to more overhead. Furthermore, 
multimedia solutions that use different, perhaps dynamic, network 
addresses for signaling and media transmission frequently suffer from 
Network Address Translation (NAT) traversal and security challenges. 


TAX is the Inter-Asterisk eXchange protocol, which facilitates VoIP 
connections between servers, and between servers and clients that 
also use the IAX protocol. IAX was created through an open source 
methodology rather than through a traditional, standards-based 
methodology. It is an open protocol originally used by Asterisk, a 
dual-licensed open source and commercial PBX server from Digium. 
Independent IAX implementations may be open, proprietary, or licensed 
in anyway the author seems fit without royalty to the protocol 
creators. 


1. Basic Properties 


IAX is a robust and full-featured, yet, simple protocol. It is 
general enough that it can handle most common types of media streams. 
However, the protocol is highly optimized for VoIP calls where low- 
overhead and low-bandwidth consumption are priorities. This 
pragmatic aspect makes IAX more efficient for VoIP than protocols 
that consider possibilities far beyond current needs and specify many 
more details than are strictly necessary to describe or transport a 
point-to-point call. Furthermore, because IAX is designed to be 
lightweight and VoIP-friendly, it consumes less bandwidth than more 
general approaches.  IAX is a binary protocol, designed to reduce 
overhead, especially in regards to voice streams. Bandwidth 
efficiency, in some places, is sacrificed in exchange for bandwidth 
efficiency for individual voice calls. For example, when 
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transmitting a voice stream compressed to 8 kbit/s with a 20 ms 
packetization, each data packet consists of 20 bytes.  IAX adds 20$ 
overhead, 4 bytes, on the majority of voice packets while RTP adds 
60$ overhead with 12 additional bytes per voice packet. 


In addition to efficiency, IAX's single static UDP port approach 
makes IAX traffic easy for network managers to shape, prioritize, and 
pass through firewalls.  IAX's basic structure is that it multiplexes 
signaling and multiple media streams over a single UDP stream between 
two computers.  IAX also uses the same UDP port for both its 
Signaling and media messages, and because all communications 
regarding a call are done over a the same point-to-point path, NAT 
traversal is much simpler for IAX than for other commonly deployed 
protocols. 


1.2. Drawbacks 


While IAX is very effective, addressing many of today's 
communications needs, it does have a few limitations. For instance, 
IAX uses a point-to-point codec negotiation mechanism that limits 
extensibility because every IAX node in a call path must support 
every used codec to some degree. In addition, the codec definition 
is controlled by an internally defined 32-bit mask, so the codecs 
must be defined in the protocol, and the maximum number of 
simultaneous codecs is, therefore, limited. 


One of IAX's design strengths also presents a potential problem. The 
use of a single, well-known, port makes the protocol an easier target 
for denial-of-service attacks. Real-time systems like VoIP are 
particularly sensitive to these attacks. 


The protocol is typically deployed with all signaling and media going 
to a centralized server. While this combined path approach provides 
a great deal of control, it limits the overall system scalability. 
IAX now provides the ability to split the media from the signaling 
stream, which overcomes this limitation of earlier IAX versions. 


Most IAX drawbacks are due to implementation issues rather than 
protocol issues.  Threading presents a series of problems. Many 
implementations have a limited number of threads available to process 
IAX traffic and can become overwhelmed by high use or denial-of- 
Service attacks. Newer implementations have additional controls to 
minimize the impact of these challenges. 
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2s 


IAX Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Additionally, this document uses the following terminology: 
Peer: A host or device that implements the IAX protocol. 


Call: A call is a relationship between two or more parties (i.e., 
resources such as devices, user agents, or programs) that exists 
for some time for the purpose of exchanging real-time media. In 
the context of this document, a call is an end-to-end relationship 
where at least the one leg of call path is implemented using the 
IAX protocol. 


Calling Party: A device or program that initiates a call. 
Called Party: A device or program to which a call is directed. 
Context: A context is a named partition of a Dialplan. 


Dialplan: A Dialplan is a set of rules for associating provided 
names and numbers with a particular called party. 


Frame: The atomic communication unit between two IAX peers. All IAX 
messages are carried within frames. 


Information Element (IE): A discrete data unit appended to an IAX 
frame that specifies user- or call-specific data. 


Registrant: A registrant is a peer that makes REGISTER requests in 
order to advertise the address of a resource, i.e., a device or 
program to which a call may be directed. 


Registrar: A registrar is a peer that processes REGISTER requests 
and places the information it receives in those requests into the 
location service. [RFC3261]. 


Overview of IAX Protocol 


IAX is a peer-to-peer, VoIP-oriented protocol.  IAX includes both 
control and media functions. It can register locations, create, 
modify, terminate multimedia sessions, and carry the actual media 
Streams specified by the sessions it manages. The protocol is 
designed and optimized for describing and transporting multimedia 
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calls using Internet Protocol. This document describes Version 2 of 
TAX; Version 1, although somewhat similar in design, utilized a 
different port and was not widely deployed. 


The basic design approach for IAX multiplexes signaling and multiple 
media streams over a single UDP association between two hosts. This 
is accomplished by using the same "well-known" UDP port, 4569, for 
all types of IAX traffic.  IAX's unified signaling and media paths 
achieve NAT transparency, which is an advantage of IAX over 
alternative media transport protocols such as SIP [RFC3261]. 


IAX is coded as a binary protocol. One major benefit of using a 
binary protocol is bandwidth efficiency because the quality of voice 
calls is frequently related to the amount of bandwidth consumed. 

This is one way the protocol is specifically optimized to make 
efficient use of bandwidth for individual voice calls. The bandwidth 
efficiency for other stream types is sacrificed for the sake of 
individual voice calls. Other benefits of a binary protocol are 
robustness against buffer-overrun attacks, and compact implementation 
capability, which reduces interoperability issues related to parsing. 


The atomic communication unit in IAX is the "Frame". There are 
multiple classes of Frames, each of which is described below. In 
general, "Full Frames" carry signaling/control data, while "Mini 
Frames" carry media stream data. Full Frames enclose optional 
‘Information Elements’ (IEs).  IEs describe various types of user- or 
call-specific data. "Meta Frames" are used for call trunking or 
video stream transmission. 


An IAX-based call may consist of many call legs, or segments. Each 
call leg may be implemented using different protocols, e.g., SIP to 
IAX to ISDN (Integrated Services Digital Network).  IAX is 


responsible for setting up one or more legs of a complete call path, 
not necessarily the end-to-end call. 


TAX is an optimized peer-to-peer protocol. If two adjacent call legs 
utilize the IAX protocol and if the intermediate peer determines that 
it does not need to remain in the call path, it can supervise a 
calling path change such that it removes itself from the path. This 
supervision is complete, a call path is not changed until all peers 
in the optimized call path confirm they can properly communicate. 


IAX supports security features by allowing multiple methods of user 
authentication and authorization, as well as allowing multiple 
security methods for peer registration.  IAX also specifies a generic 
framework for native encryption. 
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4. Naming Conventions 


Call Identifier: A call leg is marked with two unique integers, one 
assigned by each peer involved in creating the call leg. 


Number: The Calling and Called Numbers are a set of digits and 
letters identifying a call originator and the desired terminating 
resource. The term 'Number' is historic and has been expanded to 
include letters. A peer is responsible for defining its own 
dialplan. A peer MAY define its dialplan according to ITU-T 


Recommendation E.164 [E164]. However, this is not required. 
Username: A username is a string used for identification purposes. 
5. IAX Uniform Resource Identifiers 


5.1. IAX URI Scheme Registration 
This section registers IAX according to the guidelines in [RFC4395]. 
URI scheme name: 
iax. 
Status: 
Permanent. 
URI scheme syntax: 
The "iax:" scheme follows the guidelines in [RFC3986]. 
The general form is as follows: 
iax: [username@]host[:port] [/number[?context] ] 
where these tokens have the following meanings: 
iax: The literal 'iax:'. 
username: A string used for identification purposes. 
host: The domain of the resource. The host part contains 


either a fully-qualified domain name or numeric IPv4 or IPv6 
address. An IPv6 address must be enclosed within brackets 


(i.e., '[2001:db8::1]') as defined in [RFC3986]. Using the 
fully-qualified domain name form is RECOMMENDED whenever 
possible. 
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port: The numeric UDP port number. 


number: The name or number identifying the resource on that 
host. 


context: The name of the host partition in which the service 
is identified or processed. 


Examples 
iax:example.com/alice 
iax:example.com:4569/alice 
iax:example.com:4570/alice?friends 
iax:192.0.2.4:4569/alice?friends 
iax:[2001:db8::1]:4569/alice?friends 
iax:example.com/12022561414 
iax: johnQ@example.com/12022561414 


ABNF 
Formal syntax is defined using ABNF [RFC5234]. Certain values 
are included by reference from [RFC3986]: 


iax-uri = "iax:" [ userinfo "@" ] host [ ":" port ] 
[ "/" number [ "?" context ] ] 


userinfo = «as specified in RFC 3986» 
host = «as specified in RFC 3986» 
port = «as specified in RFC 3986» 
number = *(unreserved / sub-delims / pct-encoded ) 
context = *(unreserved / sub-delims / pct-encoded ) 
unreserved = «as specified in RFC 3986» 
sub-delims = <as specified in RFC 3986> 


pct-encoded «as specified in RFC 3986» 


URI Scheme Semantics: 


An IAX URI identifies a communications resource capable of 
communicating using the IAX Version 2 protocol defined in this 
document. Within this document, we refer to IAX Version 2 
protocol URI as IAX. An IAX URI contains enough information to 
initiate an IAX-based call with that resource. 
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TAX URIs are associated with server resources to which calls may 
be routed. For instance, an IAX URI may represent an appearance 
on a phone, a voice-mail box on a messaging service, an 
interactive program, a Public Switched Telephone Network (PSTN) 
address or gateway, or any group of the above. 
The IAX URI scheme translates into a location that may be used by 
the IAX protocol to establish a new call using the URI scheme 
components described in the previous section. This new call 
function is the only defined operation. 

Encoding considerations: 


IAX URI scheme encoding conforms to the encoding rules established 
for URIs in [RFC3986]. 


Applications/protocols that use this URI scheme name: 
The scheme is used by ENUM Dynamic Delegation Discovery System 
(DDDS) services to specify resources that support the IAX 
protocol. The IAX protocol provides application-layer control and 
media protocol for creating, modifying, and terminating multimedia 
sessions over Internet Protocol (IP) networks. 

Interoperability considerations: 
None. 

Security considerations: 
The IAX URI Scheme does not introduce any new security concerns 
except that it provides a uniform syntax for describing IAX 
resources and that, when published, these addresses are subject to 
various denial-of-service attacks. 

Contact: 
Ed Guy, edguy@emcsw.com, +1.973.437.4519. 

Author/Change controller 
Not Applicable. 


References: 


RFC 5456 (this document) 


Spencer, et al. Informational [Page 10] 


RFC 5456 TAX: Inter-Asterisk eXchange Version 2 February 2010 


5.2. URI Comparison 


Some operations in this specification require determining whether two 
TAX URIs are equivalent.  IAX URIS are compared for equality 
according to the following rules: 


All components of the URI MUST be identical except: 


The port, if omitted, is considered to be the same as the default, 
4569. 


All URI components, except the username field, are case 
insensitive, and MUST be normalized to lower case as per Section 
6.2.2.1 of [RFC3986] before comparison. 


The URIs within each of the following sets are equivalent: 


iax:atlanta.com/alice 
iax:AtLaNtA.com/ALicE 
iax:atlanta.com:4569/alice 


iax:aliceQatlanta.com/alice 
iax:aliceQAtLaNtA.com:4569/ALicE 


The URIs within the following set are not equivalent: 


iax:ALICEGatlanta.com/alice 
iax:aliceQatlanta.com/alice 


NOTE: A host in domain form and in IP address form are NOT considered 
identical even if the host name resolves to an address record that 
matches the given IP address. 


6. Peer Behavior and Related Messages 


Messages are divided into two categories: reliable and non- 
guaranteed. The reliable messages are referred to as "Full Frames". 
In addition to a message type indicator and facilities to ensure 
reliability, see Section 7, they include the full call identifier. 
It consists of each of peer's identifiers for the call. Additional 
attributes, "Information Elements" or "IEs", may be associated with 
the Full Frame messages. 


The non-guaranteed messages are referred to as "Mini-Frames" and 
"Meta Frames" and these more compact messages only have the 
originating peer's call identifier and MUST NOT have any "Information 
Elements". 
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Peer behavior is presented in several partitions divided by the 
following functional areas: 


Registration (OPTIONAL) 

Call Link Management 

Call Path Optimization (OPTIONAL) 
Mid-Call Behavior 

Call Tear Down 

Network Monitoring 

Digit Dialing (OPTIONAL) 
Miscellaneous 

Media Messages 


Each of these behavior topics and the messages involved are described 
in the sections that follow. 


6.1. Registration (OPTIONAL) 
6.1.1. Overview 


In order for one IAX peer to be reachable by another IAX peer, the 
calling peer needs the network address of the receiving peer. This 
address may be manually provisioned, determined through a shared 
directory, e.g. an ENUM-like service, [RFC3761] or configured using 
the IAX protocol.  IAX provides a facility for one peer to register 
its address and credentials with another so that callers can reach 
the registrant. The IAX registration facility is optional. If 
implemented, the IAX registration protocol MAY be done in parts, 
e.g., an analog telephone adapter MAY only implement the registrant 
portion of the protocol. 


IAX allows user authentication via multiple methods.  MD5 Message- 
Digest authentication [RFC1321] uses an MD5 sum arrangement, but 
still requires that both ends have plaintext access to the secret. 
(See Section 8.6.15.) Rivest, Shamir, and Adleman’s (RSA) algorithm 
[RFC3447] allows unidirectional secret knowledge through public/ 
private key pairs.  IAX Private keys SHOULD always be Triple Data 
Encryption Standard (3DES) encrypted [RFC1851]. (See 

Section 8.6.16.) 


Spencer, et al. Informational [Page 12] 


RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010 


Unregistered  |&-------------------------- N 
| 
| | 
/Init | | 
———Ó | | 
snd REGREQ | +-------- + 
| | rec REGAUTH 
V NES 0 gp esee 
| | | snd REGREQ | 
| Reg Sent +----+ 
| — i | 
| ^ | rec REGAUTH | 
rec REGACK | | | /No Credentials| 
Serene aesee REG timeout cee aioe it 
snd ack |  » | | | ------- snd ack 
| | REGREQ _v | 
y | | | 
| | | No | | 
| Registered | | Auth | 
| | | BEN | 
| | rec REGAUTH | 
| release | /No Credentials | 
—— | ------------——- | 
4------- * | snd REGREL | snd ack 
rec REGAUTH | | 
RU EE EUR D EE V V 
snd REGREL | | | ---------- + 
ql-——— + Releasing | --------------------------- + 
| | rec ACK 
x 


rec REGREJ | | 
ERG RE *-»| Rejected | 
| 


Figure 1: Registrant State Diagram 


Registration, illustrated in Figure 1, is performed by a registrant 
that sends a username and a registration 'refresh' period to the 
registrar. This is accomplished with a REGREQ message. If 
authentication is required, the registrar responds with the REGAUTH 
message that indicates the types of authentication supported by the 
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registrar. In response, the registrant resends a REGREQ with one of 
the supported authentications. If the registrant cannot 
authenticate, no further action is necessary. If accepted, the 
registrar sends a REGACK message, which MUST indicate the 'apparent 
address' and SHOULD indicate the 'refresh'/expire time. If no 
'refresh' is sent, a default registration expiration of 60 seconds 
MUST be assumed by both peers. At any time during this exchange, the 
registrar may send a REGREJ message to indicate a failure. 


A registration has a specified time period associated with it for 
which it is valid. This time period begins when the registrar sends 
a REGACK message. A registrant may extend that time period by 
repeating the registration process. A registrant MAY also force an 
expiration in the registrar by sending the REGREL message. This 
message may be challenged with REGAUTH or, if sufficient credentials 
were included, it will be accepted with REGACK. In response to a 
REGAUTH, a REGREL message SHOULD be resent using the specified 
credentials. 


See Sections 9.3 and 9.4 for example call flows. 
6.1.2.  REGREQ Registration Request Message 


The REGREQ occurs independently of any media-carrying call. A REGREQ 
MUST include the 'username' IE and SHOULD include the 'refresh' IE. 

A REGREQ is used both for an initial registration request as well as 
for a reply to a REGAUTH. As a reply to a REGAUTH message, it MUST 
include credentials such as a response to a REGAUTH's challenge. 


Upon receipt of a REGREQ message that has credentials, a registrar 
MUST determine their validity. If valid, it MUST respond with a 
REGACK message indicating the time period for which this registration 
is valid. If the provided credentials are not valid or the registrar 
cannot validate the credentials, the registrar MUST respond with a 
REGREJ message. If credentials are not provided, the registrar MUST 
respond with a REGAUTH message that indicates the available 
authentication methods. 


Registrants MUST implement this message and registrars MUST be able 
to process it. 


The following table specifies IEs for this message: 
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Username Section 8.6.6 Required 


Section 8.6.15 Conditional 


RSA Result Section 8.6.16 Conditional 


| 
| 
| MD5 Result 
| 
| per REGAUTH 


| 
| 
per REGAUTH | 
| 
| 


Refresh Section 8.6.18 Optional 
+------------ +---------------- +------------- +------------- + 


6.1.3.  REGAUTH Registration Authentication Response Message 


A REGAUTH is a response to a REGREQ or REGREL. It is sent when a 
registrar requires authentication to permit registration. A REGAUTH 
message MUST include the 'authentication methods’ and 'username' IEs, 
and the 'MD5 challenge' or 'RSA challenge' IE if the authentication 
methods include MD5 or RSA. 


Upon receipt of a REGAUTH message, the registrant MUST resend the 
REGREQ or REGREL message with one of the requested credentials, if it 


has the specified credentials. 


Registrars MUST implement this message and registrants MUST be able 
to process it. 


The following table specifies IEs for this message: 


4R-——-—---------- 4R--——------------- 4R-——---------- 4--—-----------—- * 
| IE | Section | Status | Comments 
4R--——-—---------- 4R-——------------- 4R-——---------- 4--—------------ * 
| Username | Section 8.6.6 | Required | 
Auth Methods Section 8.6.13 Required 

| | | | | 
| Challenge | Section 8.6.14 | Conditional | If RSA or MD5 | 
See a deer uere doe eee * 


6.1.4.  REGACK Registration Acknowledgment Message 


A REGACK is sent in response to a REGREQ. A REGACK typically 
includes the 'refresh' IE specifying the number of seconds before the 
registration will expire. If the 'refresh' IE is not included with a 
REGACK, a default registration expiration of 60 seconds MUST be 
assumed. A REGACK MAY also include the 'username' and 'apparent 
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address’ IEs to indicate how the peer identifies the registrant.  IEs 
related to caller identification or the time the registration 
occurred MAY be sent as well. 


Receipt of a REGACK message requires an ACK in response. 


Registrars MUST be able to send this message and registrants MUST be 
able to process it. 


The following table specifies IEs for this message: 


R-—---------------- R-—-------------- R---------- R---------- * 
| IE | Section | Status | Comments | 
4R-—---------------- 4R-—-------------- R---------- 4R---------- * 
| Username | Section 8.6.6 | Required | 
| Date Time | Section 8.6.28 | Required | 
| | | | | 
| Apparent Address | Section 8.6.17 | Required | 
| | | | | 
| Message Count | Section 8.6.23 | Optional | 
| Calling Number | Section 8.6.2 | Optional | 
| | | | | 
| Calling Name | Section 8.6.4 | Optional | 
| | | | | 
| Refresh | Section 8.6.18 | Optional | 
R------------------ R---------------- R---------- R---------- * 


6.1.5.  REGREJ Registration Rejection Message 


A REGREJ indicates that a registration request has been rejected. 
This rejection can occur for several reasons. A REGREJ MUST include 
the 'causecode' and 'cause' IEs to specify why registration was 
rejected. 


Upon receipt of a REGREJ message, the registrant MUST consider 
registration process unsuccessful and no further interaction is 
required. A peer MAY reinitiate the process at later time accounting 
for potential configuration changes on the registrar or registrant. 


Both registrants and registrars MUST be capable of sending and 
processing this message. 


The following table specifies IEs for this message: 
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4------------ 4---------------- 4---------- 4---------- - 
| IE | Section | Status | Comments | 
4------------ 4---------------- 4---------- 4---------- * 
| Cause | Section 8.6.21 | Required | 
| Cause Code | Section 8.6.33 | Required | 
4------------ 4---------------- 4---------- 4---------- * 


.6.  REGREL Registration Release Request Message 


A REGREL is used by a registrant for a forced release of a prior 
registration. It MUST include the 'username' IE to identify the 
registrant to be released, and MAY include the 'causecode' and 
‘cause’ IEs to specify why registration is being released. 


Upon receipt of this message, a peer MUST authenticate the sender 
using the provided credentials or send a REGAUTH message requesting 
them. If authenticated, it MUST immediately purge its registration 
of the specified registrant or send a REGREJ message if the 
registration is not found. 


Registrants SHOULD be capable of sending this message and registrars 
MUST be able to process it. 


The following table specifies IEs for this message: 
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4R---------- qPlnan£teeeezcccle R-—----------- Ponen asin teense MacRae cea + 
| IE | Section | Status | Comments 
4+---------- R-—-------------- R-—----------- 4-—----------------------- * 
| Username | Section 8.6.6 | Required | 
| | | | | 
| MD5 | Section 8.6.15 | Conditional | MD5 or RSA Result is | 
| Result | | | required 
| RSA | Section 8.6.16 | Conditional | 
| Result | | | 
| | | | | 
| Cause | Section 8.6.21 | Optional | 
| | | | | 
Cause Section 8.6.33 Optional 
Code 
R---------- R---------------- R------------- R-—----------------------- * 
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6.2. Call Leg Management 


5 a + HANGUP/ack 
| 
| | 
| | | 
4--------- > | Initial | <----+ 
| | pura + 
start call | | 
MEM | | 
| send NEW | +------- + | 
| fis uil | rec AUTHREQ | 
| LX XL | oc | 
| | | | snd AUTHREP | 
Torena neas Waiting seak 
ISG RM OR Ce -hA oe >+ 
aeS E | | 
ack | rec HANGUP | 
p ÉL oo | 
| snd ack | 
rec ACCEPT | 
Se es ME s | 
snd ack | | | PROCEEDING / ack | 
V V | RINGING / ack | 
| | | | 
Linked |----- + | 
------------------------ >+ 
| rec HANGUP | 
rec ANSWER | 0000000 ---------- | 
a Di d | snd ack | 
snd ack | | 
| rec HANGUP 
Vi, | 
| | snd ack | 
| UP | --------------------- >+ 
| |--------------------- >+ 
finish 
snd HANGUP 


Figure 2: Call Origination State Diagram 
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4R-------- * rec HANGUP/ack 
| | 
V rec NEW(no Auth)/snd AUTHREQ 
| | 
| Initial |----- + rec NEW(not Auth)/snd REJECT 
| | 
| |<-------------------- + 
| | 
rec NEW 
(valid credentials) 
UFU GRE ||, Seema | 
snd ACCEPT | | | snd PROCEEDING | 
V V | snd RINGING | 
| | | | 
| Linked  |----- * 
| aes aa ha : 
| rec HANGUP | 
/answered Po ZZ SÉ 1L LÀ 
ILE | snd ack | 
snd ANSWER | 
| rec HANGUP 
V p ie iL 
| | snd ack 
| UP | --------------------- >+ 
| |--------------------- >+ 
finish 
snd HANGUP 


Figure 3: Call Termination State Diagram 
6.2.1. Overview 


The IAX protocol can be used to set up 'links' or 'call legs’ between 
two peers for the purposes of placing a call. The process, 
illustrated in Figure 2 and Figure 3, starts when a peer sends a NEW 
message indicating the destination 'number' (or name) of a Called 
Party on the remote peer. The remote peer can respond with either a 
credentials challenge (AUTHREQ), a REJECT message, or an ACCEPT 
message. The AUTHREQ message indicates the permitted authentication 
Schemes and SHOULD result in the sending of an AUTHREP message with 
the requested credentials. The REJECT message indicates the call 
cannot be established at this time. ACCEPT indicates that the call 
leg between these two peers is established and that higher-level call 
Signaling (Section 6.3) MAY proceed. After sending or receiving the 
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ACCEPT message, the call leg is in the 'Linked' state and is used to 
pass call control messages until the call is completed. Further 
detail on messages used for this process can be found in Section 6.3. 


Call legs are labeled with a pair of identifiers. Each end of the 
call leg assigns the source or destination identifier during the call 
leg creation process. 


6.2.2. NEW Request Message 


A NEW message is sent to initiate a call. It is the first call- 
Specific message sent to initiate an actual media exchange between 
two peers. ‘NEW’ messages are unique compared to other Call 
Supervision messages in that they do not require a destination call 
identifier in their header. This absence is because the remote 
peer's source call identifier is not created until after receipt of 
this frame. Before sending a NEW message, the local IAX peer MUST 
assign a source call identifier that is not currently being used for 
another call. A time-stamp MUST also be assigned for the call, 
beginning at zero and incrementing by one each millisecond. Sequence 
numbers for a NEW message, described in the transport section, 
(Section 7) are both set to 0. 


A NEW message MUST include the 'version' IE, and it MUST be the first 
IE; the order of other IEs is unspecified. A NEW SHOULD generally 
include IEs to indicate routing on the remote peer, e.g., via the 
'called number' IE or to indicate a peer partition or ruleset, the 
‘called context’ IE. Caller identification and CODEC negotiation IEs 
MAY also be included. 


Upon receipt of a NEW message, the receiving peer examines the 
destination and MUST perform one of the following actions: 


Send a REJECT response, 
Challenge the caller with an AUTHREQ response, 
Accept the call using an ACCEPT message, or 


Abort the connection using a HANGUP message, although the REJECT 
message is preferred at this point in call. 


If the call is accepted, the peer MUST progress the call and further 
respond with one of PROCEEDING, RINGING, BUSY, or ANSWER depending on 
the status of the called party on the peer. See Section 6.3 for 
further details. 


The following table specifies IEs for the NEW message: 
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| | | 
| Encryption | Section 8.6.34 | Optional 


OSP Token Section 8.6.42 Optional 
+-------------- +---------------- +------------- +--------------------- + 


6.2.3. ACCEPT Response Message 


An ACCEPT response is issued when a NEW message is received, and 
authentication has taken place (if required). It acknowledges 
receipt of a NEW message and indicates that the call leg has been set 
up on the terminating side, including assigning a CODEC. An ACCEPT 
message MUST include the 'format' IE to indicate its desired CODEC to 
the originating peer. The CODEC format MUST be one of the formats 
sent in the associated NEW command. 


Upon receipt of an ACCEPT, an ACK MUST be sent and the CODEC for the 
call MAY be configured using the 'format' IE from the received 
ACCEPT. The call then waits for an ANSWER, HANGUP, or other call 
control signal. (See Section 6.3.) If a subsequent ACCEPT message 
is received for a call that has already started, or has not sent a 
NEW message, the message MUST be ignored. 


The following table specifies IEs for this message: 


4-------- R-—------------- R---------- R---------- * 
| IE | Section | Status | Comments | 
R-------- R-—------------- R---------- R-—-------- * 
| Format | Section 8.6.8 | Required | 

4R-------- R-—------------- R---------- R---------- * 


6.2.4. REJECT Response Message 


A REJECT response is sent to indicate that a NEW, AUTHREP, DIAL, or 
ACCEPT request has been denied. It MAY be due to an authentication 
failure, an invalid username, or if a peer cannot provide a valid 
password or response to an issued challenge. It MAY also be used to 
notify a peer of a call setup failure, e.g., when IAX peers cannot 
negotiate a CODEC to use. Upon receipt of a REJECT message, the call 
leg is destroyed and no further action is required. (Note: REJECT 
messages require an explicit ACK.) 


REJECT messages MAY include the 'causecode' and 'cause' IEs to 
indicate the rejection reason. 


The following table specifies IEs for this message: 
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4------------ 4---------------- 4---------- 4---------- - 
| IE | Section | Status | Comments | 
4------------ 4---------------- 4---------- 4---------- * 
| Cause | Section 8.6.21 | Optional | 
| Cause Code | Section 8.6.33 | Optional | 
4------------ 4---------------- 4---------- 4---------- * 


6.2.5. | HANGUP Request Message 


A HANGUP message is sent by either peer and indicates a call tear- 
down. It MAY include the 'causecode' and 'cause' IEs to indicate the 
reason for terminating the call. Upon receipt of a HANGUP message, 
an IAX peer MUST immediately respond with an ACK, and then destroy 
the call leg at its end. After a HANGUP message has been received 
for a call leg, any messages received that reference that call leg 
(i.e., have the same source/destination call identifiers) MUST be 
answered with an INVAL message. This indicates that the received 
message is invalid because the call no longer exists. 


After sending a HANGUP message, the sender MUST destroy the call and 
respond to subsequent messages regarding this call with an INVAL 


message. 


The following table specifies IEs for this message: 


4------------ 4---------------- 4---------- 4---------- - 
| IE | Section | Status | Comments | 
4------------ 4---------------- 4---------- 4---------- + 
| Cause | Section 8.6.21 | Optional | 
| Cause Code | Section 8.6.33 | Optional | 
4------------ 4---------------- 4---------- 4---------- * 


6.2.6. AUTHREP Authentication Reply Message 
An AUTHREP MUST include the appropriate challenge response or 
password IE, and is only sent in response to an AUTHREQ. An AUTHREP 


requires a response of either an ACCEPT or a REJECT. 


Typical reasons for rejecting an AUTHREP include 'destination does 
not exist’ and 'suitable bearer not found’. 


The following table specifies IEs for this message: 
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4------------ 4---------------- 4------------- 4---------- * 
| IE | Section | Status | Comments | 
4------------ 4---------------- 4------------- 4---------- * 
| RSA Result | Section 8.6.16 | Conditional | If RSA | 
| MD5 Result | Section 8.6.15 | Conditional | If MD5 | 
4------------ 4---------------- 4------------- 4---------- + 


6.2.7. AUTHREQ Authentication Request Message 


The AUTHREQ message is sent in response to a NEW message if 
authentication is required for the call to be accepted. It MUST 
include the 'authentication methods’ and ’username’ IEs, and the 
‘challenge’ IE if MD5 or RSA authentication is specified. 


Upon receiving an AUTHREQ message, the receiver MUST respond with an 
AUTHREP or HANGUP message. 


The following table specifies IEs for this message: 


4R-------------- R-—-------------- R---------- R-—-------- * 
| IE | Section | Status | Comments | 
4R-------------- R-—-------------- R---------- R---------- * 
| Username | Section 8.6.6 | Required | 
| | | | | 
| Auth Methods | Section 8.6.13 | Required | 
| | | | | 
| Challenge | Section 8.6.14 | Required | 
t-------------- R-—-------------- R---------- R-—-------- * 


6.3. Call Control 
6.3.1. Overview 


IAX’s call control messages provide end-to-end signaling functions 

common to other telephony control protocols. The messages include 

RINGING, ANSWER, BUSY, and PROCEEDING. These messages MUST only be 
sent after an IAX call leg has been ACCEPTed. 


In response to an exchange starting with a NEW message, typically, 
the first call control message is RINGING; however, a PROCEEDING 
message MAY precede it or the call MAY proceed directly to the ANSWER 
message. If the call is answered, an ANSWER message will be sent. 
Other possibilities include a "BUSY" indication, or if the called 
party’s service cannot be reached, the call will be torn down using 
the link-level HANGUP and an appropriate cause code. 


Spencer, et al. Informational [Page 24] 


RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010 


If the link was started with a DIAL message, the sequence is an 
optional PROCEEDING, then optional RINGING, then ANSWER or BUSY. Of 
course, a link level HANGUP MAY occur at any time. 


Various private extensions to IAX Control messages have been deployed 
for passing application-specific data over the IAX control link. One 
such extension is an application that controls ham radio 
transceivers. An IAX peer that receives a control message that is 
not understood MUST respond with the UNSUPPORT message. 


The mandatory IAX control messages are explained below. 


6.3.2. PROCEEDING Response Message 


The PROCEEDING message SHOULD be sent to a calling party when their 
call request is being processed by a further network element but has 
not yet reached the called party. 


Upon receipt of a PROCEEDING message, the peer SHOULD perform 
protocol-specific actions to indicate this fact to the calling party, 
e.g., tones, an ISUP (ISDN User Part) Proceeding message, etc. If 
the prior call leg is utilizing the IAX protocol, a PROCEEDING 
message MUST be sent to that peer. The processing of this message at 
an originating or transcoding peer is not specified; however, if 
possible, the status may be displayed to the calling party. 


The PROCEEDING message does not require any IEs. 
6.3.3. RINGING Response Message 


This message is sent from a terminating party to indicate that the 
called party's service has processed the call request and is being 
alerted to the call. An IAX RINGING message MUST be sent to an IAX- 
based calling party when the peer determines that the called party is 
being alerted, e.g., when their phone is ringing. 


Upon receipt of an IAX RINGING message, the peer MUST pass this 
indication to the calling party, unless the calling party has already 
received such indication. For an initiating peer, this is typically 
done by starting the ring-back tone; however, many implementations 
start ring-back before ringing in order to meet user expectations. 

If the calling party is using the IAX protocol, a RINGING message 
MUST be passed to this caller. 


The RINGING message does not require any IEs. 
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6.3.4. ANSWER Response Message 


This message is sent from the called party to indicate that the party 
has accepted the call request and is communicating with the calling 
party. Upon receipt of this message, any ring-back or other progress 
tones MUST be terminated and the communications channel MUST be 
opened. 


The ANSWER message does not require any IEs. 


6.4. Mid-Call Link Operations 


6.4.1. FLASH Request Message 
The FLASH message is sent to indicate a mid-call feature. Its 
interpretation is system dependent and if it is not expected, it 
SHOULD be ignored. Typically, this message is only sent from analog 


telephone adapters when a brief circuit interruption is made during 
an answered call. 


The FLASH message does not require any IEs. 

6.4.2. HOLD Request Message 
The HOLD message is sent to cause the remote system to stop 
transmitting audio on this channel, and optionally replace the audio 
with music or other sounds. If the remote system cannot perform this 


request, it SHOULD be ignored. 


The HOLD message SHOULD only be sent in IAX calls that are started 
using the DIAL message. 


The HOLD message does not require any IEs. 

6.4.3. UNHOLD Request Message 
The UNHOLD message is sent to cause the remote system to resume 
transmitting audio on this channel. If the remote system cannot 


perform this request, it SHOULD be ignored. 


The UNHOLD message SHOULD only be sent in IAX calls after the HOLD 
message. 


The UNHOLD message does not require any IEs. 
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6. 


6. 


6. 


4. 


4. 


4. 


4.  QUELCH Request Message 


The QUELCH message is sent to cause the remote peer to squelch or 
stop transmitting audio on this channel. It MAY replace the audio 
sent to the further party with music or other sounds. If the remote 
system cannot perform this request, it SHOULD be ignored. 


The QUELCH message MUST only be sent in IAX calls after an ACCEPT is 
sent or received; it SHOULD only be used on calls that are started 
using the NEW message. 


The QUELCH message does not require any IEs. 
5. UNQUELCH Request Message 


The UNQUELCH message is sent to cause the remote system to resume 
transmitting audio on this channel. If it previously replaced the 
audio with music or other sounds, it MUST discontinue it immediately. 
If the remote system cannot perform this request, it SHOULD be 
ignored. 


The UNQUELCH message SHOULD only be sent in IAX calls after the 
QUELCH message. 


The UNQUELCH message does not require any IEs. 
6. TRANSFER Request Message 


The TRANSFER message causes the receiving peer to restart the call 
using another specified number. The receiving peer MUST be on the 
calling side of this call leg and the new call behavior is 
unspecified. After processing this message, a HANGUP message SHOULD 
be sent and the call leg torn down. 


When sending a TRANSFER message, the new number to which the call is 
being transferred MUST be included in the CALLED NUMBER IE and a 
CALLED CONTEXT IE MAY be included. The call leg MUST NOT be used for 
anything else and MAY be torn down. 


The following table specifies IEs for this message: 
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t----------- +--------------- 4+---------- 4-—-------------------------- * 
| IE | Section | Status | Comments 

R-—--------- R-—------------- R---------- 4R-—-------------------------- * 
| Called | Section 8.6.1 | Required | 

| Number | | | | 
| | | | | 
| Called | Section 8.6.5 | Optional | Use this IE if context is | 
| Context | | | other than default. 
R--—--------- R-—------------- R---------- 4R-—-------------------------- * 


6.5. Call Path Optimization 


If a peer is handling a call between two other IAX peers and the peer 
no longer has any need to monitor the progress, content, or duration 
of the call, it MAY remove itself from the call by directing the 
other two peers to communicate directly. This call path 
optimization, or "supervised transfer", is done in a manner that 
ensures the call will not be lost in the process; the initiating peer 
does not give up control of the process until it has confirmed the 
other two peers are communicating. Note: the parties involved in the 
call are not aware of this operation; it is purely a network 
operation. 
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rec TXREJ | | rec TXREL 
---------- *#----—-----> None <-----------------+t 
snd TXREJ ack A 
to other | | | 
| V | 
| | 
| * (From All) 
/Init Transfer | rec TXREQ 
snd TXREQ | | snd TXCNT 
to both | | 
V. V. 
| | | 
| Begin | ----------------- >+ 
| | 
| | 
rec TXACC | | rec TXREADY 
Sarran S LL Se | 
snd TXREADY | | x | 
| | | 
V V | 
| | ----------------- >+ 
ZEEE | Ready | ---------- | 
| | | l| 
/Both Legs Ready| /Both Legs Ready| rec TXMEDIA| | 
and not cee and media-only | | 
snd TXREL | snd TXMEDIA | x | 
| | | | 
DENM D Mu = -y | 
| | | | | | | 
Release Media Media 
| | | | “ees | | 
| | | | 
| | | 
V V | 
rec TXCNT PaaS SSR SSS T >+ 
AA SSSeS (In any state) 
snd  TXACC 


Figure 4: Call Path Optimization State Diagram 
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When a peer initiates this procedure, both call legs MUST be in the 
UP state, i.e., they MUST have sent or received the ACCEPT message 
for that call leg. To start, it sends a TXREQ message with the 
addresses and information from the other remote peers to each its 
neighbors. If capable of performing this procedure, they begin 
transmitting all channel information to both the initiating peer and 
the new remote peer. They also send a TXCNT message indicating 
packet counts for the call leg to the new remote peer. Each TXCNT 
message is acknowledged with a TXACC message. The peers respond by 
sending a TXREADY message to the initiator indicating that they have 
confirmed the new communications path. When all remote peers have 
sent the initiator a TXREADY message, the transfer is successful and 
the initiator responds with a TXREL and has finished its involvement 
with the call. If during the transfer process, the two remote peers 
cannot communicate, they send a TXREJ message to the initiator. An 
example is shown in Section 9.5. 


These messages are described in the sections that follow. 

6.5.1. TXREQ Transfer Request Message 
The TXREQ message is sent by a peer to initiate the transfer process. 
When sent, it MUST be sent to both adjacent peers involved in the 


call. 


It MUST include the following Information Elements: 


R-—---------------- R-—-------------- R---------- R---------- * 
| IE | Section | Status | Comments | 
R-—---------------- R-—-------------- R---------- R---------- * 
| Apparent Address | Section 8.6.17 | Required | 
| | | | | 
| Call Number | Section 8.6.20 | Required | 
Transfer ID Section 8.6.26 Required 
P R-—-------------- R---------- R---------- * 


The Apparent Address is the IP address data structure address for the 
other remote peer. The Call Number IE is the callid used by the 
other remote peer and the Transfer ID is a unique number assigned by 
the initiator. 


Upon receipt of a TXREQ message for a valid call from the 
corresponding remote peer, a peer MUST respond by attempting to 
communicate with the newly specified remote peer. This task is 
accomplished by sending a TXCNT message directly to the peer at the 
address specified in the Apparent Address parameter. 
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6.5.2.  TXCNT Transfer Connectivity Response Message 


The TXCNT message is used to verify connectivity with a potential 
replacement peer for a call. It MUST include the TRANSFERID IE. 
Upon receipt on a message of this type, and if the peer has 
previously received a TXREQ for this call leg, the peer MUST respond 
with a TXACC message. 


If the TXCNT message is not successfully transmitted or if a TXACC 
message is not received in response to it, the transfer process MUST 


be aborted by sending a TXREJ message to the initiating host. 


It MUST include the following Information Element: 


R---------- $oce So SSS SoS SSS +---------- fee ae eee E + 
| IE | Section | Status | Comments 

R---------- R---------------- R---------- 4-—--------------------------- * 
| Transfer | Section 8.6.26 | Required | A unique number assigned | 
| ID | | | by the initiator. 
+---------- R-—--------------- R---------- 4R-—-------------------------- * 


6.5.3.  TXACC Response Message 


Like the TXCNT message, the TXACC message is used to verify 
connectivity with a potential replacement peer. It MUST include the 
TRANSFERID IE. Upon receipt on a message of this type if the peer is 
attempting to transfer this call leg, the peer stops sending call- 
related media to the initiating peer and sends a TXREADY message to 
it. 


It MUST include the following Information Element: 


R---------- R-—--------------- R---------- 4R-—-------------------------- * 
| IE | Section | Status | Comments 

R---------- R-—--------------- Ea Se aR ER oe ag a Bg E + 
| Transfer | Section 8.6.26 | Required | A unique number assigned | 
| ID | | | by the initiator. 
+---------- R---------------- R---------- Sa fesse a ce deeeccut + 


6.5.4.  TXREADY Transfer Ready Response Message 


The TXREADY message indicates that the sending peer has verified 
connectivity with the peer which it was instructed to transfer the 
call. It MUST include the TRANSFERID IE. When TXREADY messages are 
received from both remote peers, it MUST discontinue media transport 
and send a TXREL message to each peer. 


It MUST include the following Information Element: 
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+---------- 4+---------------- +---------- +---------------------------- + 
| IE | Section | Status | Comments 

+---------- 4+---------------- +---------- +---------------------------- + 
| Transfer | Section 8.6.26 | Required | A unique number assigned | 
| ID | | | by the initiator. 
+---------- 4+---------------- +---------- +---------------------------- + 


6.5.5.  TXREL Transfer Release Response Message 


The TXREL message indicates that the transfer process has 
successfully completed. After sending and upon receipt of this 
message, no further interaction (other than an ACK, of course) is 
needed between the peers on this call leg. The TXREL is also used to 
revert a split-media call (one where the media and signaling follow 
different paths) to a call where the media and signaling follow the 
same path. 


It MUST include the following Information Element: 


R------------- R-—-------------- R-—-------- R---------- * 
| IE | Section | Status | Comments | 
R------------- R---------------- R---------- R-—-------- * 
| Call Number | Section 8.6.20 | Required | 

R------------- 4R---------------- R-—-------- R---------- * 


6.5.6.  TXMEDIA Transfer Media Message 


The TXREL message indicates that the MEDIA transfer process has 
successfully completed. After sending and upon processing of this 
message, Full Frames MUST continue to follow the original signaling 
path and media frames MUST follow the newly negotiated path. This 
Split-path process continues until the call ends with a HANGUP or 
peer receives a TXREL message for the call leg. A peer MAY force the 
paths to rejoin by sending a TXREL message. 


It MUST include the following Information Element: 


4R------------- R-—-------------- R---------- 4R---------- * 
| IE | Section | Status | Comments | 
r A R---------------- R---------- S + 
| Call Number | Section 8.6.20 | Required | 

R-—----------- R-—-------------- r R---------- * 
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6.5.7.  TXREJ Transfer Rejection Response Message 


The TXREJ MAY be sent at anytime during the transfer process to 
indicate that the transfer cannot proceed. Upon receiving a TXREJ 
message, if the receiver is the initiating peer, it MUST form a TXREJ 
message and send it to the other remote peer. 


The TXREJ message does not require any IEs. 


6.6. Call Tear Down 


The messages used to finish a call vary depending on the particular 
process the call is in at the time. The terminal messages for a call 


are: 


HANGUP. See Section 6.2.5. 
REJECT. See Section 6.2.4. 
TRANSFER. See Section 6.4.6. 
TXREADY. See Section 6.5.4. 


These messages are discussed in their respective sections. Also, if 
the reliable transport procedures determine that messaging cannot be 
maintained, the call leg MUST be torn down without any other 
indications over the errant IAX call leg. 


6.7. Network Monitoring 


The IAX protocol has various tools to determine the network load. It 
uses the POKE message to monitor reachability of remote peer and the 
LAGRQ message to measure the quality of a current call leg including 
the jitter buffer delay. 


6.7.1. POKE Request Message 


A POKE message is sent to test connectivity of a remote IAX peer. It 
is similar to a PING message, except that it MUST be sent when there 
is no existing call to the remote endpoint. It MAY also be used to 
"qualify" a user to a remote peer, so that the remote peer can 
maintain awareness of the state of the user. A POKE MUST have 0 as 
its destination call number. 


Upon receiving a POKE message, the peer MUST respond with a PONG 
message. 


This message does not require any IEs. 
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6.7.2. PING Request Message 


A PING message is sent to test connectivity of the remote IAX 
endpoint on an existing call. Transmission of a PING MAY occur when 
a peer-defined number of seconds have passed without receiving an 
incoming media frame on a call, or by default every 20 seconds. 
Receipt of a PING requires an acknowledging PONG be sent. 


This message does not require any IEs. 


6.7.3. PONG Response Message 


A PONG message is a response to a PING or a POKE. It acknowledges 
the connection. The receiver uses the time-stamp of the received 
PING or POKE and its times to determine the Round Trip Time of the 


connection. Several receiver report IEs MAY be included with a PONG, 
including received jitter, received frames, delay, and dropped 
frames. Receipt of a PONG requires an ACK. 


This message does not require any IEs. 
6.7.4.  LAGRQ Lag Request Message 


A LAGRQ is a lag request. It is sent to determine the lag between 
two IAX endpoints, including the amount of time used to process a 
frame through a jitter buffer (if any). It requires a clock-based 
time-stamp, and MUST be answered with a LAGRP, which MUST echo the 
LAGRQ's time-stamp. The lag between the two peers can be computed on 
the peer sending the LAGRQ by comparing the time-stamp of the LAGRQ 
and the time the LAGRP was received. 


This message does not require any IEs. 

6.7.5.  LAGRP Lag Response Message 
A LAGRP is a lag reply, sent in response to a LAGRQ message. It MUST 
send the same time-stamp it received in the LAGRQ after passing the 
received frame through any jitter buffer the peer has configured. 
This message does not require any IEs. 

6.8. Digit Dialing 
Digit Dialing support is an optional portion of the IAX protocol 
designed to support devices that do not maintain their own dial 
plans, for instance, analog telephone adapters, or ATAs. The dialing 


portion of the IAX protocol MAY be implemented for the client/ 
phone-side, server-side or not all. The exchanges work as a series 
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of Dialing Plan requests (DPREQs) each followed by a response (DPREP) 
indicating if additional digits SHOULD be collected before sending 
the call. The sections that follow describe these messages and the 
rules associated with them. 


6.8.1. DPREQ Dial Plan Request Message 


A DPREQ is a request for the server to analyze the passed called 
number and determine if there is a valid dialing pattern on the 
remote peer. It MUST include the 'called number' IE to specify what 
extension is being queried. This command is used in the case where a 
local peer does not handle its own dialplan/extension switching. The 
local peer can inquire (as a user dials) how the remote peer 
perceives the 'called number’. If a DPREP is received indicating 
that the number is valid, a DIAL MAY be sent. 


This message MAY be sent by the client and MUST be implemented on 
servers which provide IAX dialing support. 


It MUST include the following Information Element: 


R-—----------- R-—-------------- R---------- R-—-------- * 
| IE | Section | Status | Comments | 
4R------------- R---------------- R-—-------- R---------- * 
| Call Number | Section 8.6.20 | Required | 

R-—----------- R---------------- R-—-------- R---------- * 


6.8.2. DPREP Dial Plan Response Message 


A DPREP is a reply to a DPREQ, containing the status of the dialplan 
entry requested in the 'called number' IE of the DPREQ. It MUST 
include the 'called number', 'dpstatus', and 'refresh' IEs. The 
called number is the same one received in the 'called number' IE of 
the DPREQ. The 'dpstatus' IE contains the status of the dialplan 
entry referenced by the received called number. The status indicates 
whether the called number exists, can exist, needs more digits, or is 
invalid. More information can be found in Section 8.6 under the 
DPSTATUS information element. The 'refresh' IE specifies the number 
of minutes the 'dpstatus' is valid. If the 'refresh' IE is not 
present, a default 10 minutes period is assumed. 


The sending of this message MUST be implemented by servers which 
support IAX dialing. Clients which support IAX dialing MUST be 
capable of receiving such messages. 


It MUST include the following Information Elements: 
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+---------- R-—--------------- R-—-------- 4-—--------------------------- * 
| IE | Section | Status | Comments 
R---------- R-—--------------- R---------- 4R-—-------------------------- * 
| Card | Section 8.6.20 | Required | 
| Number | | | | 
| Dial | Section 8.6.20 | Required | Indicates if number | 
| Plan | | | exists, is a partial 

Status match, etc. 
| Dial | Section 8.6.20 | Optional | Inclusion is strongly | 
| Plan | | | suggested. The default is | 
| Refresh | | | 10 minutes. 
+---------- R---------------- 4R---------- 4-—-------------------------- * 


6.8.3. DIAL Request Message 


The DIAL message is used with IAX peers that do not maintain their 
own dialplan/extension routing. Once an extension is validated by 
one or more DPREQ/DPREP exchanges, the number MAY be dialed in a DIAL 
message, using the 'called number' IE to specify the extension it is 
attempting to reach. The remote peer then handles the remaining 
aspects of call setup, including ringing the extension and notifying 
the local peer when it has been answered following the same 
requirements as the NEW command (Section 6.2.2). 


The following table specifies the IEs used by this message: 


4----------- 4--------------- 4---------- 4---------------------------- + 
| IE | Section | Status | Comments 
+----------- pcne isa +---------- toe ee eee oe ee E + 
| Called | Section 8.6.1 | Required | 
Number 
| Called | Section 8.6.5 | Optional | Use this IE if context is | 
| Context | | | other than default. 
FHoSSssssesS n e a deeESSLOLSII£SUVe-4S-£4e-—scx-Lben + 
6.9. Miscellaneous 
6.9.1. ACK: Acknowledgement Message 
An ACK acknowledges the receipt of an IAX message. An ACK is sent 
upon receipt of a Full Frame that does not have any other protocol- 
defined response. An ACK MUST have both a source call number and 
destination call number. It MUST also not change the sequence number 
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counters, and MUST return the same time-stamp it received. This 
time-stamp allows the originating peer to determine to which message 
the ACK is responding. Receipt of an ACK requires no action. 


An ACK MAY also be sent as an initial acknowledgment of an IAX 
message that requires some other protocol-defined message 
acknowledgment, as long as the required message is also sent within 
some peer-defined amount of time. This allows the acknowledging peer 
to delay transmission of the proper IAX message, which may add 
security against brute-force password attacks during authentication 
exchanges. 


When the following messages are received, an ACK MUST be sent in 
return: NEW, HANGUP, REJECT, ACCEPT, PONG, AUTHREP, REGREL, REGACK, 
REGREJ, TXREL.  ACKs SHOULD not be expected by any peer and their 
purpose is purely to force the transport layer to be up to date. 


The ACK message does not requires any IEs. 
6.9.2. INVAL: Invalid Response Message 


An INVAL is sent as a response to a received message that is not 
valid. This occurs when an IAX peer sends a message on a call after 
the remote peer has hung up its end. Upon receipt of an INVAL, a 
peer MUST destroy its side of a call. 


The INVAL message does not requires any IEs. 
6.9.3. VNAK: Voice Negative Acknowledgement Message 


A VNAK is sent when a message is received out of order, particularly 
when a Mini Frame is received before the first full voice frame on a 
call. It is a request for retransmission of dropped messages. A 
message is considered out of sequence if the received iseqno is 
different than the expected iseqno. On receipt of a VNAK, a peer 
MUST retransmit all frames with a higher sequence number than the 
VNAK message's iseqno. 


The VNAK message does not requires any IEs. 

6.9.4. MWI: Message Waiting Indicator Request Message 
An MWI message is used to indicate to a remote peer that it has one 
or more messages waiting. It MAY include the 'msgcount' IE to 


Specify how many messages are waiting. 


The following table specifies IEs used by this message: 
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4+---------- R---------------- R---------- R----------- * 
| IE | Section | Status | Comments | 
R---------- R-—--------------- R---------- 4R-—--------- * 
| MSGCOUNT | Section 8.6.23 | Optional | Suggested | 
R---------- R---------------- D A + 


6.9.5. UNSUPPORT Unsupported Response Message 


An UNSUPPORT message is sent in response to a message that is not 
supported by an IAX peer. This occurs when an IAX command with an 
unrecognized or unsupported subclass is received. No action is 
required upon receipt of this message, though the peer SHOULD be 
aware that the message referred to in the optionally included ’ IAX 
unknown’ IE is not supported by the remote peer. 


The following table specifies IEs used by this message: 


4--------- 4---------------- 4---------- 4----------- * 
| IE | Section | Status | Comments | 
4--------- 4---------------- 4---------- 4----------- * 
| UNKNOWN | Section 8.6.22 | Optional | Suggested | 
4--------- 4---------------- 4---------- 4----------- * 


6.10. Media Messages 


The IAX protocol supports many types of media and these are 
transported through the same UDP port as other IAX messages. Voice 
and video are unique in that they utilize two different encodings, 
each with different support procedures. Abbreviated 'Mini Frames’ 
are normally used for audio and video; however, each time the time- 
stamp is a multiple of 32,768 (0x8000 hex), a standard or 'Full 
Frame' MUST be sent. This approach facilitates efficiency and 
reliability by sending compressed packets, without guaranteed 
delivery, most of the time while periodically forcing reliable 
exchanges with the peer. If communication fails, call tear-down 
procedures are invoked. 


Upon receiving any media message, except the abbreviated audio and 
video Mini Frames, an ACK message MUST be sent. The content SHOULD 
be passed to an associated application, device, or call leg. The 
data MAY be buffered before it is presented to the user. 

6.10.1. DTMF Media Message 


The message carries a single digit of DTMF (Dual Tone Multi- 


Frequency). Useful background information about DTMF can be found in 
[RFCA733] and [RFC4734], but, note that IAX does not use the RTP 
protocol. 
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6.10.2. Voice Media Message 
The message carries voice data and indicates the CODEC used. 
6.10.3. Video Media Message 


The frame carries video data and indicates the video format of the 
data. 


6.10.4. Text Media Message 
The frame carries a text message in UTF-8 [RFC3629] format. 
6.10.5. Image Media Message 


This message carries a single image. The image MUST fit in one 
message in this version of the protocol. 


6.10.6. HTML Media Message 


The HTML message class carries HTML and related data as well as 
status about the display of that HTML page. The subclass parameter 
indicates the HTML content type. It MAY be a URL, the start, middle, 
or end of a data block. HTML data MUST be in the format described in 
[htm1401]. 


If a peer receives an HTML message for a channel that does not 
support HTML, it MUST respond with an HTML message that has the HTML 
NOT SUPPORTED indication. 


When a device that supports HTML completes loading the page, it 
SHOULD send a LOAD COMPLETE message 


6.10.7. Comfort Noise Media Message 
This message indicates that comfort noise SHOULD be played. It has a 
parameter that indicates the level. The noise is to be locally 
generated. 


7. Message Transport 


TAX is sent over UDP and uses an application-level protocol to 
provide reliable transport where needed. 


With respect to transport, there are two message formats: reliable or 
‘Full Frames’ and unacknowledged 'Mini' or 'Meta' frames. All 
messages except certain voice and video messages are reliable. 
Reliable messages are transported by a scheme that maintains message 
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counts and time-stamps for both peers involved in the call. The 
counts are per call. Each peer maintains a timer for all reliable 
messages and MUST periodically retransmit those messages until they 
acknowledge or the retry limit is exceeded. 


When starting a call, the outgoing and incoming message sequence 
numbers MUST both be set to zero. Each reliable message that is sent 
increments the message count by one except the ACK, INVAL, TXCNT, 
TXACC, and VNAK messages, which do not change the message count. The 
message includes the outgoing message count and the highest numbered 
incoming message that has been received. In addition, it contains a 
time-stamp that represents the number of milliseconds since the call 
started. Or, in the case of certain network timing messages, it 
contains a copy of the time-stamp sent to it.  Time-stamps MAY be 
approximate, but, MUST be in order. 


When any message is received, the time-stamps MUST be checked to make 
sure that they are in order. If a message is received out of order, 
it MUST be ignored and a VNAK message sent to resynchronize the 
peers. If the message is a reliable message, the incoming message 
counter MUST be used to acknowledge all the messages up to that 
sequence number that have been sent. 


If no acknowledgment is received after a locally configured number of 
retries (default 4), the call leg SHOULD be considered unusable and 
the call MUST be torn down without any further interaction on this 
call leg. 


7.1.  Trunking 


IAX allows multiple media exchanges between the same two peers to be 
multiplexed into a single trunk call coalescing media payload into a 
combined packet. This decreases bandwidth usage as there are fewer 
total packets being transmitted.  Trunking MAY occur in one or both 
directions of an IAX exchange. A trunk consists of a trunk header 
and one or more trunked IAX calls. The trunk message contains a 
time-stamp specifying the time of transmission of the trunk frame. 
The audio data from the trunked calls are encapsulated in the trunk 
frame following the header. Each trunked call consists of two octets 
specifying the call's source number, two octets specifying the length 
in octets of the media data, and the media data itself.  IAX permits 
transmitting the time-stamps of each encapsulated Mini Frame as well, 
So that accurate timing information can be used for jitter buffers, 
etc. A flag in the meta command header specifies whether the 
encapsulated Mini Frames retain their original time-stamps. If they 
do not retain them, they MUST assume the time-stamp in the trunk 
header upon being received by the trunk peer. 
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7.2. Timers 


There are various timers in the IAX protocol. There are other 
application-level timers, such as the call timer and ring timer, that 
are beyond the scope of this document. This section describes the 
IAX timers and specifies their default values and behaviors. 


7.2.1. Retransmission Timer 


The message retransmission procedures are described in Section 7. On 
each call, there is a timer for how long to wait for an 
acknowledgment of a message. This timer starts at twice the measured 
Round-Trip Time from the last PING/PONG command. If a retransmission 
is needed, it is exponentially increased until it meets a boundary 
value. The maximum retry time period boundary is 10 seconds. 


7.2.2. Registration Period Timer 


Registrations are valid for a specified time period. It is the 
client's responsibility to renew this registration before the time 
period expires. The registrations SHOULD be renewed at random 
intervals to prevent network congestion. A registrar MUST monitor 
this time period and invalidate the registration if the client/ 
registrant has not renewed their registration before the timer 
elapses. 


7.3. NAT Considerations 


IAX is very well suited to operating behind NAT due to its single 
port approach. This approach eliminates any start of call media 
stream delays while the NAT gateway establishes a bidirectional port 
association. Deploying a single IAX server behind a NAT gateway 
requires little effort. If the server acts as a registrar, the IAX 
UDP port on the NAT gateway must be forwarded to the server. If the 
Server acts as a registrant, the default, 60 second, REGREQ refresh 
timer should be sufficient to maintain a port association in the NAT 
gateway; however, a static port mapping is preferred. 


If multiple servers are to be deployed behind a single NAT gateway, 
most NAT gateways require each IAX server to use different UDP ports. 
Of course, there may be NAT implementations that recognize when 
multiple devices utilize the same private port and manage it 
appropriately. 
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7. 


8. 


8. 


4. Encryption 


IAX supports call encryption using the symmetric key, Rijndael [AES] 
block cipher (also called AES -- Advanced Encryption Standard). 
Rijndael is a 128-bit block cipher utilizing a shared secret.  IAX 
encrypts on a call-by-call basis starting with a plaintext NEW 
message indicating, in addition to the other message parameters, that 
the call should be encrypted. This indication is given by sending 
the ENCRYPTION IE (Section 8.6.34) in the NEW request message. If 
the called host supports encryption, it will respond with a plaintext 
AUTHREQ message that also includes the ENCRYPTION IE. All subsequent 
messages in the call MUST be encrypted. If the called host does not 
support encryption, the AUTHREQ sent in response to the NEW must not 
include the ENCRYPTION IE and the calling host MUST either HANGUP the 
request or continue with the unencrypted call. 


The key to use in encrypting the messages is computed by taking the 
CHALLENGE IE Section 8.6.14 from the AUTHREQ and concatenating any 
one of the shared passwords then computing the 128-bit MD5 digest of 
this combination. To decrypt, if there is more than one password for 
the peer, each must be tried until the message is successfully 
decoded. The key remains constant for the duration of the call. 

Only the data portion of the messages are encoded. 


Message Encoding 
1. Frame Structure 


This section contains the specification for each type of frame that 
IAX defines. 


sql Full Frames 


Full Frames can send signaling or media data. Generally, Full Frames 
are used to control initiation, setup, and termination of an IAX 
call, but they can also be used to carry stream data (though this is 
generally not optimal). 


Full Frames are sent reliably, so all Full Frames require an 
immediate acknowledgment upon receipt. This acknowledgment can be 
explicit via an 'ACK' message (see Section 8.4) or implicit based 
upon receipt of an appropriate response to the Full Frame issued. 


The standard Full Frame header length is 12 octets. 
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Field descriptions: 


"EC bit 
This bit specifies whether or not the frame is a Full Frame. If 
the 'F' bit is set to 1, the frame is a Full Frame. If it is set 


to 0, it is not a Full Frame. 
Source call number 


This 15-bit value specifies the call number the transmitting 
client uses to identify this call. The source call number for an 
active call MUST NOT be in use by another call on the same client. 
Call numbers MAY be reused once a call is no longer active, i.e., 
either when there is positive acknowledgment that the call has 
been destroyed or when all possible timeouts for the call have 
expired. 


"R' bit 


This bit specifies whether or not the frame is being 
retransmitted. If the 'R' bit is set to 0, the frame is being 
transmitted for the first time. If it is set to 1, the frame is 
being retransmitted.  IAX does not specify a retransmit timeout; 
this is left to the implementor. 


Destination call number 


This 15-bit value specifies the call number the transmitting 
client uses to reference the call at the remote peer. This number 
is the same as the remote peer's source call number. The 
destination call number uniquely identifies a call on the remote 
peer. The source call number uniquely identifies the call on the 
local peer. 


Time-stamp 


The time-stamp field contains a 32-bit time-stamp maintained by an 
IAX peer for a given call. The time-stamp is an incrementally 
increasing representation of the number of milliseconds since the 
first transmission of the call. 


OSeqno 
The 8-bit OSeqno field is the outbound stream sequence number. 
Upon initialization of a call, its value is 0. It increases 


incrementally as Full Frames are sent. When the counter 
overflows, it silently resets to 0. 


Spencer, et al. Informational [Page 43] 


RFC 5456 TAX: Inter-Asterisk eXchange Version 2 February 2010 


8. 


1 


ISeqno 


The 8-bit ISeqno field is the inbound stream sequence number. 
Upon initialization of a call, its value is 0. It increases 
incrementally as Full Frames are received. At any time, the 
ISeqno of a call represents the next expected inbound stream 
sequence number. When the counter overflows, it silently resets 
to 0. 


Frametype 


The Frametype field identifies the type of message carried by the 
frame. See Section 8.2 for more information. 


'C' bit 


This bit determines how the remaining 7 bits of the Subclass field 
are coded. If the 'C' bit is set to 1, the Subclass value is 
interpreted as a power of 2. If it is not set, the Subclass value 
is interpreted as a simple 7-bit unsigned integer. 


1 2 3 
Q1 2. 3-445.26- 4 89:0: 1-2 3: 4-5-6- L:8.9: 01.2: 3-4- 5.6: 7,:8:29 x0: 3l. 
T—R——R-—R— —L—.— -—— —L—— LL —— 4-4 MM Bt 
|F] Source Call Number |R] Destination Call Number | 
t-+-+-4+-+4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4-4-4t-4+-4-4-4+-4t-4-4+-4-4-4 
| time-stamp | 
t—+—-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4-4-4+-4-4 
| OSeqno ISeqno Frame Type KA Subclass 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4+-4-4+-4-4-4 
: Data : 
T—R———R—.———t -— -—L—R———.— —— 4-446 
Figure 5: Full Frame Binary Format 
.2. Mini Frames 


Mini Frames are so named because their header is a minimal 4 octets. 
Mini Frames carry no control or signaling data; their sole purpose is 
to carry a media stream on an already-established IAX call. They are 
sent unreliably. This decision was made because VoIP calls typically 
can miss several frames without significant degradation in call 
quality while the incurred overhead in ensuring reliability increases 
bandwidth requirements and decreases throughput. Further, because 
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voice calls are typically sent in real time, lost frames are too old 
to be reintegrated into the audio stream by the time they can be 
retransmitted. 


Field descriptions: 
CE spit 


Mini Frames MUST have the 'F' bit set to 0 to specify that they 
are not Full Frames. 


Source call number 


The source call number is the number that is used by the 
transmitting peer to identify the current call. 


time-stamp 


Mini frames carry a 16-bit time-stamp, which is the lower 16 bits 
of the transmitting peer's full 32-bit time-stamp for the call. 
The time-stamp allows synchronization of incoming frames so that 
they MAY be processed in chronological order instead of the 
(possibly different) order in which they are received. The 16-bit 
time-stamp wraps after 65.536 seconds, at which point a full frame 
SHOULD be sent to notify the remote peer that its time-stamp has 
been reset. A call MUST continue to send mini frames starting 
with time-stamp 0 even if acknowledgment of the resynchronization 
is not received. 


The F bit, source call number, and 16-bit time-stamp comprise the 
entire 4-octet header for a full frame. Following this header is the 
actual stream data, of arbitrary length, up to the maximum supported 
by the network. 


Mini frames are implicitly defined to be of type 'voice frame’ 
(frametype 2; see Section 8.2). The subclass is implicitly defined 
by the most recent full voice frame of a call (i.e. the subclass for 
a voice frame specifies the CODEC used with the stream). The first 
voice frame of a call SHOULD be sent using the CODEC agreed upon in 
the initial CODEC negotiation.  On-the-fly CODEC negotiation is 
permitted by sending a full voice frame specifying the new CODEC to 
use in the subclass field. 
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jJ 2 3 
01234567829 0123456789012345678901 
T——R—R—t-——t--—t-—t--t-—t--—t-—b--t-t--t-t-t-t-t-t-t-t-t-t-t-t- 
| E | Source call number | time-stamp 
tata tata tata ta tata ta tito ta ta tata tata ta tata ta tata tata tata tatatatat 
| 


| 
: Data : 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 6: Mini Frame Binary Format 


8.1.3. Meta Frames 


Meta frames serve one of two purposes. Meta video frames allow the 
transmission of video streams with an optimized header. They are 
similar in purpose to mini voice frames. Meta trunk frames are used 
for trunking multiple IAX media streams between two peers into one 
header, to further minimize bandwidth consumption. 


8.1.3.1. Meta Video Frames 
Field descriptions: 
CE DIE 


Meta video frames MUST have the 'F' bit set to 0 to indicate that 
they are not full frames. 


Meta Indicator 


The meta indicator is a 15-bit field of all zeroes, used to 
indicate that the frame is a Meta Frame. Meta Frames are 
identifiable because the first 16 bits will always be zero in any 
Meta Frame, whereas Full or Mini Frames will have either the 'F"'" 
bit set or some (nonzero) value for the source call number (or 
both). 


'V' bit 


The 'V' bit in a meta video frame is set to 1 to specify that the 
frame is a meta video frame. 


Source call number 


The call number that is used by the transmitting peer to identify 
this video call. 
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time-stamp 


Meta video frames carry a 16-bit time-stamp, which is the lower 16 
bits of the transmitting peer’s full 32-bit time-stamp for the 
call. When this time-stamp wraps, a Full Frame SHOULD be sent to 
notify the remote peer that the time-stamp has been reset to 0. 


Following the time-stamp is the actual video stream data. Meta video 
frames are implicitly defined to be of type ‘video frame’ (frametype 
3; see Section 8.2). The video CODEC used is implicitly defined by 
the subclass of the most recent full video frame of a call. 


1 2 3 
Od, 2 34 5-6 7.8.9-0.1 2 3.4.5.6 7.8 98 Od, 2. 3 4 5-6 TBO Oe L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


|F] Meta Indicator |v] Source Call Number | 
*—R—4—4—4-—4-t-t-t-t--t--t-t-t-t-t-—t-—t-— 4-4 —À——4-4-4-4-4-4-4-4 
|2] time-stamp | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Data | 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 7: Meta Video Frame Binary Format 
8.1.3.2. Meta Trunk Frames 


IAX natively supports two methods of trunking multiple media streams 
between two peers into a single association. The first method sends 
a standard meta header, along with a single 32-bit time-stamp 
describing the transmission time of the trunk frame. Following the 
time-stamp are one or more media frames consisting of the call number 
and the length in octets of the stream data included in the frame. 


The second method of trunking is very similar to the first. It sends 
a standard meta header, including the 32-bit time-stamp describing 
the time of transmission of the trunk frame. But the media frames 
included in the trunk are actually complete Mini Frames, including 
the 16-bit time-stamp for each call. The first method uses slightly 
less bandwidth (2 fewer octets per call in the trunk), while the 
second method maintains the individual time-stamps for each call so 
that jitter buffering can use the actual time-stamps associated with 
a call instead of the (less accurate) time-stamp representing the 
entire trunk. Either method is permissible for trunking. 
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Field descriptions: 
"EC bit 


Meta trunk frames MUST have the 'F' bit set to 0 to indicate that 
they are not Full Frames. 


Meta Indicator 


The meta indicator is a 15-bit field of all zeroes, used to 
indicate that the frame is a Meta Frame. Meta Frames are 
identifiable because the first 16 bits will always be zero in any 
Meta Frame, whereas Full or Mini Frames will have either the 'F'" 
bit set or some (nonzero) value for the source call number (or 
both). 


'V' bit 


The 'V' bit in a meta trunk frame is set to 0 to specify that the 
frame is not a meta video frame. 


Meta Command 


This 7-bit field identifies whether or not the Meta Frame is a 
trunk. A value of '1' indicates that the frame is a meta trunk 
frame. All other values are reserved for future use. See the 
IANA Registry for additional IAX Meta Command Assignments. 


Command Data 


This 8-bit field specifies flags for options that apply to a 
trunked call. The least significant bit of the field is the 
‘trunk time-stamps' flag. A value of 0 indicates that the calls 
in the trunk do not include their individual time-stamps. A value 
of 1 indicates that the calls do each include their own time- 
stamp. All other bits are reserved for future use. 


time-stamp 


Meta trunk frames carry a 32-bit time-stamp, which represents the 
actual time of transmission of the trunk frame. This is distinct 
from the time-stamps of the calls included in the trunk. 


Following the 32-bit time-stamp is one or more trunked calls. If the 
'trunk time-stamps' flag is set to 0, each entry consists of 2 octets 
specifying the source call number of the call, 2 octets specifying 
the length in octets of the media data, and then the media data. If 
the 'trunk time-stamps' flag is set to 1, each entry consists of 2 
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octets specifying the length in octets of the media data, and then a 
Mini Frame (2 octets specifying source call number, 2 octets 
specifying 16-bit time-stamp, and the media data). The following two 
diagrams help illustrate this structure. 


1 2 3 
012345678901234567890123456789041 
—t———t-t-L——--.-—L—L--t-—t--t-4-—L—4- -L——t-t-t-t-t-t-t- 
| Meta Indicator |v|Meta Command | Cmd Data (0) 

*—R--———L-- -4— L—.-—- —L—.--t -—4--t--—L—t-t-t--—t-t-t- 


rrj 


-+ 
time-stamp | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-+ 


Source Call Number Data Length (in octets) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


. — + — +— + — + 
I W 
+—+ 


Data : 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


FoF HH Ht rtm a S A A E A AS BM BM E 
|R] Source Call Number Data Length (in octets) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


| 
: Data : 
| | 


+-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4+-4+-4+-4+-4+-4-4+-4-4-4+-4-4-4-4-4-4-4-4-4 


+ 
| 
+ 
| 


Figure 8: Meta Trunk Frame Binary Format (trunk time-stamps 0) 
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i 2 3 
0:1..2-3-4 5 6 7 9 9 0. 12 3. 4 5-6 748 9 0 12 3 4.5 6 7 9 9.0 1 
*—4—4—4-—4-4-.-t-t-t---t-t-t-t-t-t-—L-L-— 4 —4—4—4-4-4-4-4-4-4-4 
F | Meta Indicator |v|Meta Command | Cmd Data (1) 
T—4—R—4-—4-—t-t-t------t-t-—t-—L-— 4-4 ——4—4-—4-4-4-4- -t--4- 


| 

+ 

time-stamp | 
————R—.-——-—R—R—R—R——R—R— RM BM MM MÀ M 4—.-.-t-t-t 
| 
+ 
| 
| 
| 


Data Length (in octets) |R] Source Call Number 

—t-—t-t-t-—t-—tL-—tL—L—4————4—4-—4-4-4-t-t-t-t-t---t-t-t-t-t-t-4- 
time-stamp | 

—t-t-t-t-t-t-t-t-t-k-4-4-4-t-t-t 


+ 
| 
+ 
| 
+ 
| 
+ 
| 
+ 
| Data 

| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


T—R—4—4—4-4-—.-t-t-t----*-t-t-t-t-—t-—tL-—L-4— ——4—4-4-4-4-4-4-4-4 
| Data Length (in octets) |R] Source Call Number | 
T—R—4—4—4-—.-—t-t-t-t-t---t-t-t-t-—t-—t-—L-— 4-4 —4—4—4-4-4-4-4-4-4-4 
| time-stamp 

*—R—4—4-4-4-4-t-t--------4 

| Data | 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 9: Meta Trunk Frame Binary Format (trunk time-stamps 1) 
8.1.4. Encrypted Frames 


All of the above frames may be encrypted. The header call numbers 
are passed through in the clear, first 4 bytes for a Full Frame or 2 
bytes for a Mini Frame. The remainder of the frame is padded with 
between 16 and 32 bytes of random data, then encrypted with AES each 
block being XOR’d with the previous block. The padding is added at 
the front of the data. 


Figure 10 shows a padded Full Frame before encryption, and Figure 11 
shows the frame after encryption. Other frame types follow the same 
procedure, except the cleartext portion is shorter, as described 
above. 
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1 2 3 
01234567890123456789012345678901 
T—R—4—4—4-—.-t-t-t--t---t-t-t-t-—t-t-—L-—L-4— —À——4—4-4-4-4-4-4-4 
|F] Source Call Number |R] Destination Call Number | 
Fatt tata tata tata tartan tanta ta tat t tata tata HHMH MHH 

12 Random bytes | 

———— ee ee A ee eee 
28 Random bits | padding | 
—t-—t-t-t-——tL—tL-—L———4—4-—4-—4-.-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t- 


oe — + — + ———— 


between 0 and 15 (as indicated by the padding field above) 
: Random bytes : 
——————————— 
Remainder of Actual Frame | 
E EEEE E RETE 
Figure 10: Full Frame before encryption 


Since AES requires a 16 byte block size, some padding is essential. 
This padding has been placed at the beginning of the payload because 
it makes it more difficult to take advantage of the predictability of 
the IAX frame header. For example, the first encrypted Frame an IAX 
client sends within an incoming IAX call is entirely predictable: It 
is always an ACK - where even the time-stamp is guessable as it is 
the time the AUTHREP packet was sent. 


1 2 3 
0D.L 2-3.4 5.6 78 90) L 2.2304 5 6.7 8 9 0.1.2 3-4 5 6 7 8980.1 
T—R—4—4—4-—4-—t-t--t----*-t-t-t-—t-L-—t-— -4— ——4—4—4-4-4-4-4-4-4 
|F] Source Call Number |R] Destination Call Number | 
Sn Sn Sn Si SS Se Se ee es es es ee ee 
| Encrypted data | 
Multiple of 16 bytes 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 11: Frame after encryption 


The same encryption rules apply to the Mini Frames, except that the 
initial unencrypted portion is only 2 bytes. 
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8.2. Frame Types 
The IAX protocol specifies 10 types of possible frames for the 
"frametype" field of a Full Frame. They are described in the 
following subsections. 

8.2.1. DTMF Frame 
The frame carries a single digit of DTMF (Dual Tone Multi-Frequency). 
More information about DTMF can be found in RFC 4733 [RFC4733] and 
[RFC4734]. 


For DIMF frames, the subclass is the actual DTMF digit carried by the 
frame. 


8.2.2. Voice Frame 
The frame carries voice data. 


The subclass specifies the audio format of the data.  Predefined 
voice formats can be found in Section 8.7. 


8.2.3. Video Frame 


The frame carries video data. 


The subclass specifies the video format of the data. Predefined 
video formats can be found in Section 8.7. 


8.2.4. Control Frame 


The frame carries session control data, i.e., it refers to control of 
a device connected to an IAX endpoint. 


The subclass is a value from Section 8.3 describing the device 
control signal. 


8.2.5. Null Frame 
Frames with the Null value MUST NOT be transmitted. 

8.2.6.  IAX Frame 
The frame carries control data that provides IAX protocol-specific 
endpoint management. This frametype is used to manage IAX protocol 


interactions that are generally independent of the type of endpoints. 


The subclass is a value from Section 8.4 describing an IAX event. 
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8.2.7. Text Frame 


The frame carries a non-control text message in UTF-8 [RFC3629] 
format. 


All text frames have a subclass of 0. 
8.2.8. Image Frame 

The frame carries a single image. 

The subclass describes the format of the image from Section 8.7. 
8.2.9. HTML Frame 

The frame carries HTML data. 


The subclass is a value from the HTML Subclasses table in 
Section 8.5. 
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Comfort Noise Frame 


The frame carries comfort noise. 


The subclass is the level of comfort noise in -dBov. 


The following table specifies valid Frame Type Values: 


4------ R------------- + 
| TYPE | Description | 
4+------ 4+------------- + 
| 0x01 | DTMF | 
| | | 
| 0x02 | Voice | 
| | | 
| 0x03 | Video | 
| 0x04 | Control | 
| | | 
| | | 
| 0x05 | Null | 
| 0x06 | IAX Control | 
| | | 
| | | 
| 0x07 | Text | 
| | | 
| 0x08 | Image | 
| 0x09 | HTML | 
| | | 
| OxOA | Comfort | 
| | Noise | 
+------ +------------- + 


Audio Compression Format 
Video Compression Format 


See Control Frame Types 


Undefined 


See IAX Protocol 
Messages 


Always 0 


Image Compression Format 
See HTML Frame Types 


Level in -dBov of 


comfort noise 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


Data Description 
Undefined 

Data 

Data 


Varies with 
subclass 


Undefined 


Information 
Elements 


Raw Text 
Raw image 
Message Specific 


None 


Refer to the IANA Registry for additional IAX Frame Type values. 
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8.3. Control Frames Subclasses 


The following table specifies valid Control Frame Subclasses: 


R------------- R-—------------- tan S A T + 

| VALUE | Name | Description | 

R-—----------- R-—------------- A E ES A A E ET + 

| 0x01 | Hangup | The call has been hungup at the 

| | | remote end | 

| 0x02 | Reserved | Reserved for future use 

| | | | 
0x03 Ringing Remote end is ringing (ring-back) 

| | | | 

| | | | 

| 0x04 | Answer | Remote end has answered 

| 0x05 | Busy | Remote end is busy 

| | | | 

| 0x06 | Reserved | Reserved for future use 

| | | | 

| 0x07 | Reserved | Reserved for future use 

| 0x08 | Congestion | The call is congested 

| | | | 

| 0x09 | Flash Hook | Flash hook | 

| | | | 

| Ox0a | Reserved | Reserved for future use 

| 0x0b | Option | Device-specific options are being 

| | | transmitted | 

| | | | 

| Ox0c | Key Radio | Key Radio 

| | | | 

| Ox0d | Unkey Radio | Unkey Radio 

| Ox0e | Call Progress | Call is in progress 

| | | | 

| OxOf | Call | Call is proceeding 

| | Proceeding | | 

| 0x10 | Hold | Call is placed on hold 

| | | | 

| 0x11 | Unhold | Call is taken off hold | 

R------------- R-—------------- Fann E E r E + 


Refer to the IANA Registry for additional IAX Control Frame Subclass 
values. 


Spencer, et al. Informational [Page 55] 


RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010 


8.4. IAX Frames 


Frames of type 'IAX' are used to provide management of IAX endpoints. 
They handle IAX signaling (e.g., call setup, maintenance, and tear- 
down). They MAY also handle direct transmission of media data, but 
this is not optimal for VoIP calls. They do not carry session- 
Specific control (e.g., device state), as this is the purpose of 
Control Frames. The IAX commands are listed and described below. 


The following table specifies all valid IAX Frame values: 


———ÉÁ——————MÁ——Á———————Ó———————————— + 
Description | 


p Initiate a new call 
Ping request 

Ping or poke reply 
ACK 


Explicit acknowledgment 


HANGUP Initiate call tear-down 


REJECT Reject a call 


ACCEPT Accept a call 


AUTHREP 
0x0a INVAL Invalid message 
0x0b LAGRO Lag request 
0x0c LAGRP Lag reply 
Ox0d REGREQ Registration request 
Ox0e REGAUTH Registration authentication 
Ox0f REGACK Registration acknowledgement 
0x10 REGREJ Registration reject 
0x11 REGREL Registration release 


+ + 
| | 
+ + 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
0x08 | AUTHREQ | Authentication request 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 


| 
| 
| 
| 
| 
| 
| 
| 
Authentication reply 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
Oxlc | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 
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VNAK 


DPREQ 


DPREP 


DIAL 


TXREQ 


TXCNT 


TXACC 


TXREADY 


TXREL 


TXREJ 


QUELCH 


UNQUELCH 


POKE 


Reserved 


MWI 


UNSUPPORT 


TRANSFER 


Reserved 


Reserved 


Reserved 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


Video/Voice retransmit request 


Dialplan 
Dialplan 
Dial 

Transfer 
Transfer 
Transfer 
Transfer 
Transfer 


Transfer 


request 


reply 


request 
connect 
accept 
ready 
release 


reject 


Halt audio/video 


Resume audio/video 


Poke request 


Reserved for future use 
Message waiting indication 
Unsupported message 

Remote transfer request 
Reserved for future use 
Reserved for future use 


Reserved for future use 


[media] transmission 


[media] transmission 


February 2010 


Refer to the IANA Registry for additional IAX Frame values. 
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8.5. HTML Command Subclasses 


IAX HTML Command Subclasses: 


+-------- 4R-—-------------------------- * 
| NUMBER | DESCRIPTION | 
+-------- 4R-—-------------------------- * 
| 0x01 | Sending a URL 

| 0x02 | Data frame | 
| | | 
| 0x04 | Beginning frame | 
| | | 
| 0x08 | End frame | 
| | | 
| 0x10 | Load is complete | 
| 0x11 | Peer does not support HTML | 
| | | 
| Ox12 | Link URL | 
| | | 
| 0x13 | Unlink URL | 
| 0x14 | Reject Link URL 

Paananen O == + 


Refer to the IANA Registry for additional IAX HTML Command Subclass 
values. 


8.6. Information Elements 
IAX messages sent as Full Frames MAY carry information elements to 
specify user- or call-specific data. Information elements are 
appended to a frame header in its data field. Zero, one, or multiple 
information elements MAY be included with any IAX message. 


Information elements are coded as follows: 


The first octet of any information element consists of the "IE" 
field. The IE field is an identification number that defines the 


particular information element. Table 1 lists the defined 
information elements and each information element is defined below 
the table. 


The second octet of any information element is the "data length" 
field. It specifies the length in octets of the information 
element’s data field. 
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The remaining octet(s) of an information element contain the 
actual data being transmitted. The representation of the data is 
dependent on the particular information element as identified by 
its "IE" field. Some information elements carry binary data, some 
carry UTF-8 [RFC3629] data, and some have no data field at all. 
Elements that carry UTF-8 MUST prepare strings as per [RFC3454] 
and [RFC3491], so that illegal characters, case folding, and other 
characters properties are handled and compared properly. The data 
representation for each information element is described below. 


The following table specifies the Information Element Binary Format: 


1 
0 d. 2: 34 5-6-'L.8:.9-0.1 2 34:5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IE | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
: DATA : 


i — HÀ 


The following is a table of the information elements IAX defines, and 
a brief description of each information element's purpose. More 
information about each IE may be found below the table. 
R--—---- deeee———4—ea Spa Sa ee Se e SA Se Sate CU eS IS + 
| HEX | NAME | DESCRIPTION 
R-—---- R-——------------- 4-——---------------------------------------- + 
| HEX | NAME | DESCRIPTION 
| 0x01 | CALLED NUMBER | Number/extension being called 
| 0x02 | CALLING NUMBER | Calling number 
| 0x03 | CALLING ANI | Calling number ANI for billing | 
0x04 | CALLING NAME Name of caller 
| 0x05 | CALLED CONTEXT | Context for number 
| 0x06 | USERNAME | Username (peer or user) for 
| | | authentication | 
| 0x07 | PASSWORD | Password for authentication 
| 0x08 | CAPABILITY | Actual CODEC capability 
| 0x09 | FORMAT | Desired CODEC format 
Ox0a LANGUAGE Desired language 
| Ox0b | VERSION | Protocol version 
| OxOc | ADSICPE | CPE ADSI capability 
| OxOd | DNID | Originally dialed DNID 
| Ox0e | AUTHMETHODS | Authentication method(s) 
Ox0f | CHALLENGE Challenge data for MD5/RSA 
| 0x10 MD5 RESULT MD5 challenge result 
| Ox11 | RSA RESULT | RSA challenge result 
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APPARENT ADDR 


REFRESH 
DPSTATUS 
CALLNO 
CAUSE 

IAX UNKNOWN 
MSGCOUNT 
AUTOANSWER 
MUSICONHOLD 
TRANSFERID 
RDNIS 
Reserved 
Reserved 
DATETIME 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
CALLINGPRES 
CALLINGTON 
CALLINGTNS 
SAMPLINGRATE 
CAUSECODE 
ENCRYPTION 
ENCKEY 
CODEC PREFS 
RR JITTER 
RR LOSS 

RR PKTS 

RR DELAY 
RR DROPPED 
RR OOO 
OSPTOKEN 


Table 1: 


Inter-Asterisk eXchange Version 2 


Apparent address of peer 
When to refresh registration 
Dialplan status 

Call number of peer 

Cause 

Unknown IAX command 

How many messages waiting 
Request auto-answering 


Request musiconhold with QUELCH 


Transfer Request Identifier 
Referring DNIS 

Reserved for future 
Reserved for future 
Date/Time 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved for future 
Reserved for future 


| 
| 
| 
| 
| 
| use 
| 
| 
| 
| 
| 
| Calling presentation 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


use 


future 
future 
future 
future 


for 
for 
for 
for 


use 
use 
use 
use 
use 
use 


Calling type of number 


Calling transit network select 


Supported sampling rates 
Hangup cause 

Encryption format 
Reserved for future Use 
CODEC Negotiation 
Received jitter, 
Received loss, 
Received frames 


Max playout delay for received frames in 


ms 
Dropped frames 
buffer) 

Frames received Out of Order 
OSP Token Block 


Information Element Definitions 


as in RFC 3550 
as in RFC 3550 


(presumably by jitter 


February 2010 


the IANA Registry for additional IAX Information Element 


al. 
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8. 


8. 


.6. 


6. 


6. 


1. CALLED NUMBER 


The purpose of the CALLED NUMBER information element is to indicate 
the number or extension being called. It carries UTF-8-encoded data. 
The CALLED NUMBER information element MUST use UTF-8 encoding and not 
numeric data because destinations are not limited to E.164 numbers 
([E164]), national numbers, or even digits. It is possible for a 
number or extension to include non-numeric characters. The CALLED 
NUMBER IE MAY contain a SIP URI, [RFC3261] or a URI in any other 
format. The ability to serve a CALLED NUMBER is server dependent. 


The CALLED NUMBER information element is generally sent with IAX NEW, 
DPREQ, DPREP, DIAL, and TRANSFER messages. 


1 
QUT 2:03. 4.05.56: 8.9 0:712 3:45 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 0x01 | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+— + 


UTF-8-encoded CALLED NUMBER 


+ — 


2. CALLING NUMBER 


The purpose of the CALLING NUMBER information element is to indicate 
the number or extension of the calling entity to the remote peer. It 
carries UTF-8-encoded data. 


The CALLING NUMBER information element is usually sent with IAX NEW 
messages. 


1 
01234567890123 45 
A ——— 
| 0x02 | Data Length 
+-+-+-+-+-+-+-+-+-+-+ +++ 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


— +— + 


UTF-8-encoded CALLING NUMBER 


+ — + 


3. CALLING ANI 


The purpose of the CALLING ANI information element is to indicate the 
calling number ANI (Automatic Number Identification) for billing. It 
carries UTF-8-encoded data. 
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The CALLING ANI information element MAY be sent with an IAX NEW 
message, but it is not required. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 0x03 | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+— + 


UTF-8-encoded CALLING ANI 


+ — » 


8.6.4. CALLING NAME 


The purpose of the CALLING NAME information element is to indicate 
the calling name of the transmitting peer. It carries UTF-8-encoded 
data. 


The CALLING NAME information element is usually sent with IAX NEW 
messages. 


1. 
0123456789012345 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

0x04 | Data Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


++ 
++ 


UTF-8-encoded CALLING NAME 


+ — 
+ — 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
8.6.5. CALLED CONTEXT 
The purpose of the CALLED CONTEXT information element is to indicate 
the context (or partition) of the remote peer’s dialplan that the 


CALLED NUMBER is interpreted. It carries UTF-8-encoded data. 


The CALLED CONTEXT information element MAY be sent with IAX NEW or 
TRANSFER messages, though it is not required. 
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8. 


6. 


.6. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 0x05 | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


++ 


UTF-8-encoded CALLED CONTEXT 


+ — 


6. USERNAME 


The purpose of the USERNAME information element is to specify the 
identity of the user participating in an IAX message exchange. It 
carries UTF-8-encoded data. 


The USERNAME information element MAY be sent with IAX NEW, AUTHREQ, 
REGREQ, REGAUTH, or REGACK messages, or any time a peer needs to 
identify a user. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 0x06 | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+— + 


UTF-8-encoded USERNAME 


+ —ee 


7. CAPABILITY 


The purpose of the CAPABILITY information element is to indicate the 
media CODEC capabilities of an IAX peer. Its data is represented in 
a 4-octet bitmask according to Section 8.7. Multiple CODECs MAY be 
specified by logically OR’ing them into the CAPABILITY information 
element. 


The CAPABILITY information element is sent with IAX NEW messages if 
appropriate for the CODEC negotiation method the peer is using. 
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8. 


8. 


6. 


6. 


t 

OE 25304-56078. 9.0.02 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 0x08 | 0x04 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| CAPABILITY according to Media 
| Format Subclass Values Table 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 


+ —— + — + 


8. FORMAT 


The purpose of the FORMAT information element is to indicate a single 
preferred media CODEC. When sent with a NEW message, the indicated 
CODEC is the desired CODEC an IAX peer wishes to use for a call. 

When sent with an ACCEPT message, it indicates the actual CODEC that 
has been selected for the call. Its data is represented in a 4-octet 
bitmask according to Section 8.7. Only one CODEC MUST be specified 
in the FORMAT information element. 


1 

01.2.3. 45 679 9. 0 1:2 3 4-5 
*—R—-.-—L--.-4—4-- -4—4-4-4- 
| 0x09 | 0x04 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| FORMAT according to Media 

| Format Subclass Values Table 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-— 


+ —— + — + 


9. LANGUAGE 


The purpose of the LANGUAGE information element is to indicate the 
language in which the transmitting peer would like the remote peer to 
send signaling information. It carries UTF-8-encoded data and tags 
should be selected per [RFC5646] and [RFC4647]. 


The LANGUAGE information element MAY be sent with an IAX NEW message. 


I 
(0 e aS E 5.6 7 8 9 0.1 2 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 0x0a | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


++ 


UTF-8-encoded LANGUAGE 


+ — 
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8.6.10. VERSION 


The purpose of the VERSION information element is to indicate the 
protocol version the peer is using. Peers at each end of a call MUST 
use the same protocol version. Currently, the only supported version 
is 2. The data field of the VERSION information element is 2 octets 
long. 


The VERSION information element MUST be sent with an IAX NEW message. 


When sent, the VERSION information element MUST be the first IE in 
the message. 


ï 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x0b | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x0002 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


8.6.11.  ADSICPE 


The purpose of the ADSICPE information element is to indicate the CPE 
(Customer Premises Equipment) ADSI (Analog Display Services 
Interface) capability. The data field of the ADSICPE information 
element is 2 octets long. 


The ADSICPE information element MAY be sent with an IAX NEW message. 


1 
0. 12.345 67 8.9012 34 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x0c | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ADSICPE Capability | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


8.6.12. DNID 
The purpose of the DNID information element is to indicate the Dialed 
Number ID, which may differ from the ’called number’. It carries 


UTF-8-encoded data. 


The DNID information element MAY be sent with an IAX NEW message. 
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1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+— 
| 0x0d | Data Length 
*—L—-.——.-- -——4-- -—4--4- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


++ 


UTF-8-encoded DNID Data 


+ — 


8.6.13. | AUTHMETHODS 


The purpose of the AUTHMETHODS information element is to indicate the 
authentication methods a peer accepts. It is sent as a bitmask two 
octets long. The table below lists the valid authentication methods. 


The AUTHMETHODS information element MUST be sent with IAX AUTHREQ and 
REGAUTH messages. 


1 
Orb 2-334 5 6 7 8 9 0 L2 34-5 
E —— NR 
| 0x0e | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Valid Authentication Methods | 
a 


The following table lists valid values for authentication: 


4R-------- 4-------------------------- + 
| METHOD | DESCRIPTION | 
+-------- 4-------------------------- + 
| 0x0001 | Reserved (was Plaintext) | 
| 0x0002 | MD5 

| | | 
| 0x0004 | RSA | 
.R-------- 4-------------------------- + 


Refer to the IANA Registry for additional IAX Authentication Method 
values. 


8.6.14. CHALLENGE 
The purpose of the CHALLENGE information element is to offer the MD5 


or RSA challenge to be used for authentication. It carries the 
actual UTF-8-encoded challenge data. 
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The CHALLENGE information element MUST be sent with IAX AUTHREQ and 
REGAUTH messages. 


1 
O22. 3. 42320 P58 9-0: 1:253 4-5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Ox0f | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


: UTF-8-encoded Challenge Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.15. MD5 RESULT 


The purpose of the MD5 RESULT information element is to offer an MD5 
response to an authentication CHALLENGE. It carries the UTF-8- 
encoded challenge result. The MD5 Result value is computed by taking 
the MD5 [RFC1321] digest of the challenge string and the password 
string. 


The MD5 RESULT information element MAY be sent with IAX AUTHREP and 
REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE 
has been received. This information element MUST NOT be sent except 
in response to a CHALLENGE. 


I 
Od, 2 3.4556 y 89 0 L2 354 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 0x10 | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+—+ 


UTF-8-encoded MD5 Result 


+—ee 


8.6.16. RSA RESULT 


The purpose of the RSA RESULT information element is to offer an RSA 
response to an authentication CHALLENGE. It carries the UTF-8- 
encoded challenge result. The result is computed as follows: first, 
compute the SHA1 digest [RFC3174] of the challenge string and second, 
RSA sign the SHA1 digest using the private RSA key as specified in 
PKCS 41 v2.0 [PKCS]. The RSA keys are stored locally. 


Upon receiving an RSA RESULT information element, its value must be 


verified with the sender’s public key to match the SHA1 digest 
[RFC3174] of the challenge string. 
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The RSA RESULT information element MAY be sent with IAX AUTHREP and 
REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE 
have been received. This information element MUST NOT be sent except 
in response to a CHALLENGE. 


1 
01234567890123 45 
+ot-t-t-t-t-4-4-4-4-4-4+-4-4-t-t- 
| 0x11 | Data Length 
+-+-+-+-+-+-+-+-+-+-+ +++ 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


— +— + 


UTF-8-encoded RSA Result 


+ — 


8.6.17. APPARENT ADDR 


The purpose of the APPARENT ADDR information element is to indicate 
the perceived network connection information used to reach a peer, 
which may differ from the actual address when the peer is behind NAT. 
The APPARENT ADDR IE is populated using the source address values of 
the UDP and IP headers in the IAX message to which this response is 
generated. The data field of the APPARENT ADDR information element 
is the same as the POSIX sockaddr struct for the address family in 
use (i.e., sockaddr_in for IPv4, sockaddr_in6 for IPv6). The data 
length depends on the type of address being represented. 


The APPARENT ADDR information element MUST be sent with IAX TXREQ and 
REGACK messages. When used with a TXREQ message, the APPARENT ADDR 
MUST specify the address of the peer to which the local peer is 
trying to transfer its end of the connection. When used with a 
REGACK message, the APPARENT ADDR MUST specify the address it uses to 
reach the peer (which may be different than the address the peer 
perceives itself as in the case of NAT or multi-homed peer machines). 


The data field of the APPARENT ADDR information element is the same 
as the Linux struct sockaddr_in: two octets for the address family, 
two octets for the port number, four octets for the IPv4 address, and 
8 octets of padding consisting of all bits set to 0. Thus, the total 
length of the APPARENT ADDR information element is 18 octets. 


The following diagram demonstrates the generic APPARENT ADDR format: 
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Í 

0.1.2-3:4 5.6 7 8 9 0.1 2 3 4 5 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| 0x12 | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| sockaddr struct | 

: for address family in use E 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

The following diagram demonstrates the APPARENT ADDR format for an 
IPv4 address: 


1 
01234567890123 45 


—+-+4+-4+-4+-+-4-4+-+-+4+-4+-+-+-4-4+-4- 
0x12 | 0x10 
—+-+4+-4+-4+-+-4-4+-+-+4+-4+-+-+-4+-4+-4- 
0x0200 <- Address family (INET) 
—+-+4+-4+-4+-+-4+-4+-+-+4+-4+-4+-+4+-4+-4-4- 
Ox11d9 «- Portno (default 4569) 


—+-+4+-4+-4+-+-4+-4+-+-+4+-4+-4+-4+-4+-4+-4- 
32-bit IP address 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


8 octets of all Os 
(padding in sockaddr_in) 


—— + —— + — + — + — ++ 
—— + —— + — + — + — +H 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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The following diagram demonstrates the APPARENT ADDR format for an 
IPv6 address: 


1 

0123456789012345 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

0x12 | 0x1C 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
0x0A00 

—4t-+-4+-4+-4+-4+-4+-4-4+-+4+-4-4+-4+-4-4- 
0x11d9 

—t-+-4+-4+-4+-4+-4+-4+-4+-4+-4-4+-4+-4-4- 
32 bits 


<- Address family (INET6) 
<- Portno (default 4569) 


<- Flow information 


*——4—4—4—« 
+——+—+—4+—+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
128-bit IP address <- Ip6 Address 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


32 bits <- Scope ID 


+ —— + 
+ —— + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
8.6.18. REFRESH 


The purpose of the REFRESH information element is to indicate the 
number of seconds before an event expires. Its data field is 2 
octets long. 


The REFRESH information element is used with IAX REGREQ, REGACK, and 
DPREP messages. When sent with a REGREQ, it is a request that the 
peer maintaining the registration set the timeout to REFRESH seconds. 
When sent with a DPREP or REGACK, it is informational and tells a 
remote peer when the local peer will no longer consider the event 
valid. The REFRESH sent with a DPREP tells a peer how long it SHOULD 
store the received dialplan response. 


If the REFRESH information element is not received with a DPREP, the 
expiration of the cache data is assumed to be 10 minutes. If the 
REFRESH information element is not received with a REGACK, 
registration expiration is assumed to occur after 60 seconds. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x13 | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 2 octets specifying refresh | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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8.6.19. DPSTATUS 


The purpose of the DPSTATUS information element is to indicate the 
status of a CALLED NUMBER in a remote dialplan. Its data field is a 
2-octet bitmask specifying flags from the table below. Exactly one 
of the low 3 bits MUST be set, and zero, 1, or 2 of the high 2 bits 
MAY be set. 


The DPSTATUS information element MUST be sent with IAX DPREP 
messages, as it is the payload of the dialplan response. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x14 | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IM|R| In|c|g| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The following table lists the dialplan status flags: 


+-------- R-—---------------------------- * 
| FLAG | DESCRIPTION | 
E E I NA + 
| 0x0001 | Exists | 
| | | 
| 0x0002 | Can exist | 
| 0x0004 | Non-existent 

| | | 
| 0x4000 | Retain dialtone (ignorepat) | 
| | | 
| 0x8000 | More digits may match number | 
+-------- tan E N T + 


Refer to the IANA Registry for additional IAX dialplan status values. 
8.6.20. CALLNO 


The purpose of the CALLNO information element is to indicate the call 
number a remote peer needs to use as a destination call number to 
identify a call being transferred. The peer managing a transfer 
sends the CALLNO for one transfer endpoint to the other transfer 
endpoint so that it knows what call number to specify for the 
transfer. The data field is 2 octets long and specifies a call 
number in the same manner as a source call number or destination call 
number is specified in a frame header. 
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The CALLNO information element MUST be sent with IAX TXREQ, TXREADY, 
and TXREL messages. Transferring cannot succeed if the CALLNO IE is 
not included with the appropriate transfer messages. 


1 
0:.43..23:4 5.6 7 8 9 0 cL 2.3 45 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x15 | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Callno of transfer recipient | 
m 


8.6.21. CAUSE 


The purpose of the CAUSE information element is to indicate the 
reason an event occurred. It carries a description of the CAUSE of 
the event as UTF-8-encoded data. Notification of the event itself is 
handled at the message level. 


The CAUSE information element SHOULD be sent with IAX HANGUP, REJECT, 
REGREJ, and TXREJ messages. 


ni 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x16 | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
: UTF-8-encoded CAUSE of event : 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.22. IAX UNKNOWN 


The purpose of the IAX UNKNOWN information element is to indicate 
that a received IAX command was unknown or unrecognized. The l-octet 
data field contains the subclass of the received frame that was 
unrecognized. 


The IAX UNKNOWN information element MUST be sent with IAX UNSUPPORT 
messages. 
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n 
0.1.2.34 5067890 122345 
T—R—4—4-4-—4-4-t-t--------4 
| 0x17 | 0x01 | 
*—R—4—4-4-4-4-t-t-t-------4 
| Rec'd Subclass | 
ES 


8.6.23. | MSGCOUNT 


The purpose of the MSGCOUNT information element is to indicate how 
many voicemail messages are waiting in a registered user's mailbox. 
The data field is 2 octets long. If it is set to all 1s, there is at 
least one message present. Any other value specifies the number of 
old messages in the high 8 bits and the number of new messages in the 
low 8 bits. 


The IAX MSGCOUNT information element MAY be sent with IAX REGACK 
messages. 


1 
0123456789 012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| 0x18 | 0x02 | 
T—R—4—4-4-4-4-t-t-t-------4 
| Old messages | New messages | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.24. | AUTOANSWER 


The purpose of the AUTOANSWER information element is to request that 
a call be auto-answered upon receipt of a NEW message that includes 
the AUTOANSWER information element. Note that this is a request and 
may or may not be granted by the remote peer. There is no data field 
with this information element, as its presence alone indicates all 
necessary information. 


The AUTOANSWER information element MAY be sent with IAX NEW messages. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
| 0x19 | 0x00 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
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8.6.25. MUSICONHOLD 


The purpose of the MUSICONHOLD information element is to request that 
music-on-hold be played while a call is in the QUELCH state. The 
optional data field specifies a music-on-hold class to be used, as 
UTF-8-encoded data. In the absence of a data field, no music-on-hold 
class is specified and the IE SHOULD be treated as a generic request 
for music-on-hold. 


The MUSICONHOLD information element MAY be sent with IAX QUELCH 
messages. 


If no MUSICONHOLD information element is received, music-on-hold is 
not requested. 


1i 
0123456789 012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Oxla | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
: Optional Music On Hold Class : 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.26. TRANSFERID 


The purpose of the TRANSFERID information element is to identify a 
transfer across all three peers participating in a transfer event. 
It carries a number, four octets long, that SHOULD be unique for the 
duration of the transfer process. 


The TRANSFERID information element SHOULD be sent with IAX TXREQ and 
TXCNT messages to aid the peers involved in a transfer in identifying 
the proper calls. It is not required as long as the transferring 
peers can positively identify the calls participating in the transfer 
without the TRANSFERID. 


1 
Ovid 2 3A DEAT 28.90) 102 73:4. 75 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| Ox1b | 0x04 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| 4-octet transfer | 
| identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
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8.6.27. | RDNIS 


The purpose of the RDNIS (Redirected Dialed Number Identification 
Service) information element is to indicate the referring DNIS. It 
carries UTF-8-encoded data. 


1 
0 1.2.3.4 5.6 7 8 9:0 12 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Oxle | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+— + 


UTF-8-encoded RDNIS 


+ — 


8.6.28. DATETIME 


The DATETIME information element indicates the time a message is 
sent. This differs from the header time-stamp because that time- 
stamp begins at 0 for each call, while the DATETIME is a call- 
independent value representing the actual real-world time. The data 
field of a DATETIME information element is four octets long and 
stores the time as follows: the 5 least significant bits are seconds, 
the next 6 least significant bits are minutes, the next least 
significant 5 bits are hours, the next least significant 5 bits are 
the day of the month, the next least significant 4 bits are the 
month, and the most significant 7 bits are the year. The year is 
offset from 2000, and the month is a 1-based index (i.e., January == 
1, February == 2, etc.). The timezone of the clock MUST be UTC to 
avoid confusion between the peers. 


The DATETIME information element SHOULD be sent with IAX NEW and 
REGACK messages. However, it is strictly informational. 


1 
OT 2.3.4 56 7 8 9 0.12 34 5 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Ox1f | 0x04 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
year | month | day 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
hours | minutes | seconds 
a a S n A E A A A A 


+— + —+— + 
+— + —+— + 


Spencer, et al. Informational [Page 75] 


RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010 


8.6.29. CALLINGPRES 


The purpose of the CALLINGPRES information element is to indicate the 
calling presentation of a caller. The data field is 1 octet long and 
contains a value from the table below. 


The CALLINGPRES information element MUST be sent with IAX NEW 
messages. 


1 
0:d. 2-3 456—118 9.0.1 2 3 4 5 
————————— P AG 
| 0x26 | 0x01 | 
———————— M— 
| Calling Pres. | 
I 


The following table lists valid calling presentation values: 


4------ 4------------------2-------2--2---2--2------ * 
| FLAG | PRESENTATION | 
4------ 4------------------2---------2----------- + 
| 0x00 | Allowed user/number not screened | 
| | | 
| 0x01 | Allowed user/number passed screen | 
| | | 
| 0x02 | Allowed user/number failed screen | 
| 0x03 | Allowed network number 

| | | 
| 0x20 | Prohibited user/number not screened | 
| | | 
| 0x21 | Prohibited user/number passed screen | 
| 0x22 | Prohibited user/number failed screen | 
| | | 
| 0x23 | Prohibited network number | 
| | | 
| 0x43 | Number not available 

4------ 4------------------2-------2--2----------- * 


Refer to the IANA Registry for additional IAX Calling Presentation 
values. 
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8.6.30. CALLINGTON 


The purpose of the CALLINGTON information element is to indicate the 
calling type of number of a caller, according to ITU-T Recommendation 
Q.931 specifications. The data field is 1 octet long and contains 
data from the table below. 


The CALLINGTON information element MUST be sent with IAX NEW 
messages. 


1 
0.1. 2: 354-15 262 B39" 0: he 22 3-45 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x27 | 0x01 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Calling TON | 
+-+-+-+-+-+-+-+-+ 


The following table lists valid calling type of number values from 
ITU-T Recommendation Q.931: 


+------- toa = + 
| VALUE | DESCRIPTION | 
+------- tons + 
| 0x00 | Unknown | 
| | | 
| 0x10 | International Number | 
| 0x20 | National Number | 
| | | 
| 0x30 | Network Specific Number | 
| | | 
| 0x40 | Subscriber Number | 
| 0x60 | Abbreviated Number | 
| | | 
| 0x70 | Reserved for extension | 
+-------— Teer a EE + 


Refer to the IANA Registry for any additional IAX Calling Type of 
Number values. 


8.6.31. CALLINGTNS 
The CALLINGTNS information element indicates the calling transit 
network selected for a call. Values are chosen according to ITU-T 


Recommendation Q.931 specifications. The data field is two octets 
long. The first octet stores the network identification plan in the 
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least significant four bits according to the first table below, and 
the type of network in the next three least significant bits 
according to the second table below. The second octet stores the 
actual network identification in UTF-8-encoded data. 


The CALLINGTNS information element MUST be sent with IAX NEW 
messages. 


1 

Qui Z3 4-526 T BOO) 1:2. 3:4. 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x28 | 0x02 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| | ToN | Plan | UTF-8 Net ID | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

The following tables list the valid values for the data field of the 
‘calling tns’ IE. 


Q.931 Network Identification Plan Values: 


+------ R-—-------------------------------- * 
| BITS | DESCRIPTION | 
+------ R-—-------------------------------- * 
| 0000 | Unknown | 
| | | 
| 0001 | Caller Identification Code | 
0011 Data Network Identification Code 
+------ R-—-------------------------------- * 


Refer to the IAX Transit Network Identification IANA Registry for any 
additional values. 


Q.931 Type of Network Values: 


4------ R-—------------------------------------ * 

| BITS | DESCRIPTION 

4------ tan E + 
000 User Specified 

| 010 | National Network Identification | 

| 011 | International Network Identification | 

+------ Fann = + 


Refer to the IAX Type of Network IANA Registry for any additional 
values. 
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8.6.32. SAMPLINGRATE 


The purpose of the SAMPLINGRATE information element is to specify to 
a remote IAX peer the sampling rate in hertz of the audio data being 
the peer will use when sending data. Its data field is 2 octets 
long. 


If the SAMPLINGRATE information element is not specified, a default 
sampling rate of 8 kHz may be assumed. 


1 
0.1. 2: 354-5 6: 30:819 20:1. 22 37-455 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x29 | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sampling Rate in Hertz | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


8.6.33. CAUSECODE 


The purpose of the CAUSECODE information element is to indicate the 
reason a call was REJECTed or HANGUPed. It derives from ITU-T 
Recommendation Q.931. The data field is one octet long and contains 
an entry from the table below. 


The CAUSECODE information element SHOULD be sent with IAX HANGUP, 
REJECT, REGREJ, and TXREJ messages. 


1 
0123-45678 9 0 123 4 5 
*—R—4—4-4-4-4-t-t------t-t-4 
| Ox2a | 0x01 | 
*—R—4—4-4-4-4-t-t--------4 
| Cause Code | 
T-—4—4—4-4-4-4-4-4 
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quu Ass SoS SSS Sa Se SS SS SSS Se SSS SS Sa ese ease + 
| NUMBER | CAUSE | 
+-------- Oo eee ee ee a Lm ee UL ee eee + 
| 1 | Unassigned/unallocated number 

| 2 | No route to specified transit network 

| 3 | No route to destination 

| 6 | Channel unacceptable 

| 7 | Call awarded and delivered 

| 16 | Normal call clearing 

17 User busy 
| 18 | No user response 

| 19 | No answer | 
21 Call rejected 
| 22 | Number changed | 
| 27 | Destination out of order 

28 Invalid number format/incomplete number 

| 29 | Facility rejected 

| 30 | Response to status enquiry 

31 | Normal, unspecified 

| 34 | No circuit/channel available 

| 38 | Network out of order 

41 Temporary failure 

| 42 | Switch congestion 

| 43 | Access information discarded 

44 | Requested channel not available 

| 45 | Preempted (causes.h only) 
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| 47 | Resource unavailable, unspecified (Q.931 only) 

| 50 | Facility not subscribed (causes.h only) 

| 52 | Outgoing call barred (causes.h only) 

| 54 | Incoming call barred (causes.h only) 

| 57 | Bearer capability not authorized 

| 58 | Bearer capability not available 

| 63 | Service or option not available (Q.931 only) 

65 Bearer capability not implemented 

| 66 | Channel type not implemented 

| 69 | Facility not implemented 

70 | Only restricted digital information bearer capability is 
available (Q.931 only) 

| 79 | Service or option not available (Q.931 only) 

| 81 | Invalid call reference 

| 82 | Identified channel does not exist (Q.931 only) 

| 83 | A suspended call exists, but this call identity does not | 

| | (Q.931 only) | 

84 | Call identity in use (Q.931 only) 

| 85 | No call suspended (Q.931 only) 

| 86 | Call has been cleared (Q.931 only) 

| 88 Incompatible destination 

| 91 | Invalid transit network selection (Q.931 only) 

| 95 | Invalid message, unspecified 

96 | Mandatory information element missing (Q.931 only) 

| 97 | Message type nonexistent/not implemented 
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| 98 | Message not compatible with call state 
| 99 | Information element nonexistent 
| 100 | Invalid information element contents 
| 101 | Message not compatible with call state 
| 102 | Recovery on timer expiration 
| 103 | Mandatory information element length error (causes.h | 
| | only) | 
| 111 | Protocol error, unspecified 
127 Internetworking, unspecified 
+-------- E a A e A A E A E + 


Refer to the IAX Cause Codes IANA Registry for any additional values. 
8.6.34. ENCRYPTION 


The purpose of the ENCRYPTION information element is to indicate what 
encryption methods are accepted for an IAX peer. The data field is a 
2-octet bitmask specifying which encryption methods from the table 
below are accepted. 


The ENCRYPTION information element MAY be sent with IAX NEW and 
AUTHREQ messages. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x2b | 0x01 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Encryption Methods | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The following table lists valid native encryption methods: 


4R-------- 4R------------- * 
| METHOD | DESCRIPTION | 
4R-------- 4R------------- + 
| 0x0001 | AES-128 | 
4R-------- 4------------- * 
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Refer to the IAX Encryption Methods IANA Registry for any additional 
values. 


8.6.35. CODEC PREFS 


The purpose of the CODEC PREFS information element is to indicate the 
CODEC preferences of the calling peer. The data field consists of a 
list of CODECs in the peer’s order of preference as UTF-8-encoded 
data. 


The CODEC PREFS information element MAY be sent with IAX NEW 
messages. 


If the CODEC PREFS information element is absent, CODEC negotiation 
takes place via the CAPABILITY and FORMAT information elements. 


1 
0I. 23 4.536 7 8:90 l.2.-3:«4-5 
I —— —— 
| 0x2d | Data Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


—+— + 


CODEC Prefs Data 


+ — 


8.6.36. RR JITTER 


The purpose of the Receiver Report (RR) JITTER information element is 
to indicate the received jitter on a call, per [RFC3550]. The data 
field is 4 octets long and carries the current measured jitter. 


The RR JITTER information element MAY be sent with IAX PONG messages. 


1 
0123456789012345 
+-+-4+-4+-+-+4+-4+-4+-+-4-+-+-+4+-+-4+-4+-4+ 
| 0x2e | 0x04 | 
+-+-4+-4+-+-+-4+-+-+-4+-+-+-+4+-+-4+-4+-4+ 

Received Jitter 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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8.6.37. RR LOSS 


The purpose of the RR LOSS information element is to indicate the 
number of lost frames on a call, per [RFC3550]. The data field is 4 
octets long and carries the percentage of frames lost in the first 
octet, and the count of lost frames in the next 3 octets. 


The RR LOSS information element MAY be sent with IAX PONG messages. 


1 
0.1. 2-3 4 5.6 7.8.9.0 12 3 4 5 
—t-—k-t-t-k-t-t-4--t-4---4--4 
0x2f | 0x04 | 
—tL-—t-t-t-k-t-t-k--t-4-x--4--4 
Loss Percent | | 
+ 


—t-+-+-4+-+-4+-+- Loss Count 


+—+—4+—+4+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.38. RR PKTS 


The purpose of the RR PKTS information element is to indicate the 
total number of frames received on a call, per [RFC3550]. The data 
field is 4 octets long and carries the count of frames received. 


The RR PKTS information element MAY be sent with IAX PONG messages. 


1 
Of 236 Aoi: 7 8:970. 1:2: 3:4. 75 
A ————— :— 
| 0x30 | 0x04 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Frames Received Count | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

8.6.39. RR DELAY 
The purpose of the RR DELAY information element is to indicate the 
maximum playout delay for a call, per [RFC3550]. The data field is 2 
octets long and specifies the number of milliseconds a frame may be 


delayed before it MUST be discarded. 


The RR DELAY information element MAY be sent with IAX PONG messages. 
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1 
0.1.2.345678 9 012 34 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x31 | 0x02 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Maximum Playout Delay | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


8.6.40. RR DROPPED 


The purpose of the RR DROPPED information element is to indicate the 
total number of dropped frames for a call, per [RFC3550]. The data 
field is 4 octets long and carries the number of frames dropped. 


The RR DROPPED information element MAY be sent with IAX PONG 
messages. 


T 
0123456789012 345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x32 | 0x04 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Total Frames Dropped | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
8.6.41. RR OOO 


The purpose of the RR OOO information element is to indicate the 
number of frames received out of order for a call, per [RFC3550]. 
The data field is 4 octets long and carries the number of frames 
received out of order. 


The RR OOO information element MAY be sent with IAX PONG messages. 


1 
0-1 2.9.4556 7 8 9 O 2 3 4.5 
—— —— 
| 0x33 | 0x04 | 
+-4-4-4-4-4-4-4-4-4+-4-4-4-4-4-4-4 
| Frames Received | 
| Out of Order | 
C 
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8.6.42. OSPTOKEN 


The purpose of the OSPTOKEN information element is to carry European 
Telecommunications Standards Institute (ETSI) Technical Specification 
101 321 [OSP] (also referred to as the Open Settlement Protocol or 
OSP) tokens. The OSP tokens will be used to provide authorization, 
authentication and account support for IAX by using the OSP protocol. 
The first octet of the data field is the OSP token block index 
starting from 0. 


The OSPTOKEN information element MAY only be sent with IAX NEW 
messages. If the token is not supported by the receiver, it is 
ignored. 


1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x34 | Data Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Block Index | | 
+-+-+-+-+-+-+-+-+ + 
| OSP Token Block | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


8.7. Media Formats 


Media Format Values 


little-endian 


| suscrass | DESCRIPTION | LENGTH CALCULATION SOS | 
| 0x00000001 | &.723.1 e endo ad-ayve nene tor 240" | 
| | | samples | 
| 0x00000002 | GSM Full Rate | 33-byte chunks of 160 samples or | 
| | | 65-byte chunks of 320 samples | 
| 0x00000004 | G.711 mu-law | 1 byte per sample 

| 0x00000008 G.711 a-law 1 byte per sample 

| 0x00000010 | G.726 | | 
| 0x00000020 | IMA ADPCM | 1 byte per 2 samples 

0x00000040 | 16-bit linear | 2 bytes per sample 

| | | | 
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| 0x00000080 | LPC10 | Variable size frame of 172 samples | 
| 0x00000100 | G.729 | 20-byte chunks of 172 samples 
| 0x00000200 | Speex | Variable 
| 0x00000400 | ILBC | 50 bytes per 240 samples 
| 0x00000800 | G.726 AAL2 | | 
| 0x00001000 | G.722 | 16 kHz ADPCM 
| 0x00002000 | AMR | Variable 
| 0x00010000 | JPEG | 
| 0x00020000 | PNG | | 
| 0x00040000 | H.261 | | 
| 0x00080000 | H.263 | | 
| 0x00100000 | H.263p | | 
| 0x00200000 | H.264 | | 
AE A E E E E E Sys e See SS SasSSs + 
Refer to the IANA Registry for any additional IAX Media Format 
values. 

9. Example Message Flows 
This section includes call flow diagrams for some of the various 
types of IAX calls that can be made. In each diagram, rs! 
character represents a Full Frame and the ’-’ character represents a 
Mini Frame. Notes applicable to a generic call may be presented 
alongside each diagram. 
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9.1. Ping/Pong 


PING->PONG 
Peer A Peer B 
| | 
T 
i PING > 
n | | 
e | < PONG | Has same time-stamp 
| | as received PING. 
| | ACK > |Has same time-stamp 
| | | as received PONG 
A | | and original PING. 


9.2.  Lagrq/Lagrp 


LAGRO->LAGRP 


Peer A Peer B 
| | 
T | | 
i LAGRO > 
m 
e | < LAGRP=== |Same time-stamp as 
| | received LAGRQ. 
| | ACK > |Same time-stamp as 
| | | received LAGRP and 
X3. | | original LAGRQ. 
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9.3. Registration 


Registration of an IAX Peer 


Registrant A Registrar B 
| | 
T | ===REGREQ > | 
i 
m | < REGAUTH=== | 
e | | 
| ===REGREQ > | 
| | | 
| | < REGACK=== | 
\ / 
\}/ ACK > 
| | 
| | 
9.4. Registration Release 


Registration Release 


Registrant A Registrar B 
| | 
T | ===REGREL > | 
i | | 
m | < REGAUTH=== | 
e | | 
===REGREL > 
| 
| « REGACK--- 
SR RE: 
NI 


| | 
| | 
/ | ACK > | 
| | 
| | 
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9.5. Call Path Optimization 


IAX Transfer 


Peer L Peer C Peer R 
| | | 
T | 
<== TXREQ =====[*]== TXREQ =========> C requests transfer 
i | | | 
| TXCNT ==> |L sends to R 
mo | | | 
| < TXACC ==== |R replies 
e | | |R sends Media 
to L 
| 
| | = TXREADY ====> | |L tells C 'ready' 
| | | | C stops media to L 
| | | | 
| | <== TXCNT |L sends to R 
| 
| | === TXACC R replies 
Su j | | 
| | <== TXREADY ------ |R tells C 'ready' 
| | | C stops media to R 
| | | 
| <== TXREL =====[*]== TXREL =========> i Releases 
| | 
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9.6. IAX Media Call 


Complete end-to-end IAX media exchange 


Peer A Peer B 
| 
NEW > 
T | < AUTHREQ=== 
| 
i | ====AUTHREP > 
m | < ACCEPT=== 
e | ACK > 
| 
< Voice (Full Frame)=== 
ACK > 
| | 
| | <--------- Voice Mini Frame (ring)-- 
| | <--------- Voice Mini Frame (ring)-- 
| | 
\ / < RINGING=== 
NI ACK > 
| 
| «--------- Voice Mini Frame (ring) -- 
| «--------- Voice Mini Frame (ring) -- 
| 
< ANSWER=== 
ACK > 
| 
| ====Voice (Full Frame) > 
| < ACK 
| 
| &K----------- Voice Mini Frames------ > 
| «--- ---» 
| <--- ; ---» 
| <----------- Voice Mini Frames------ > 
| ====Voice (Full Frame) > 
| <===ACK 
| 
| < Voice (Full Frame)==== 
| ACK > 
| 
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If authentication 
specified. 


exchange Occurs 


note 1) 
note 2) 
every 65536 ms) 


( 
( 
( 
(note 3) 
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| <----------- Voice Mini Frames------ = [i 
-N ces HM 
«--- F ---> 
«--- A ---> 
| <----------- Voice Mini Frames------ > | 
| | 
| ====HANGUP > | Either can hangup 
| < ACK | 


Note 1: Mini Frames carry the low 16 bits of the peer’s 
32-bit time-stamp. 

Note 2: Full frames resync the 32-bit time-stamp when the 16-bit 
time-stamp overflows. 

Note 3: Each side has its own 32-bit time-stamp so each side needs 
to sync at 16-bit overflow. 
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IAX Media Call via an IAX Device 


An IAX peer is not required to maintain a complete dialplan. 
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February 2010 


In the 


event that a user wishes to dial from an IAX peer that does not 
the following call flow diagram may represent 


switch its own calls, 
the transaction: 


B 


Peer A (IAX Device) Peer 
| 
| NEW > 
T | < AUTHREQ=== 
i | ====AUTHREP > 
m | < ACCEPT=== 
e | ACK > 
| ====DPREQ > 
| | < DPREP=== 
| | 
| | DIAL > 
< PROGRES S=== 
ACK > 
Mex WE x ANSWER--- 
Nb | ACK > 
| 
| ====Voice (Full Frame) > 
< ACK 
< Voice (Full Frame)==== 
| ACK > 
| 
| 
| <----------- Voice Mini Frames------ > 
<a ---» 
d RM ---> 
| <--- : ---> 
| <----------- Voice Mini Frames------ > 
| 
| 
====Voice (Full Frame) > 
| <===ACK 
| 
| < Voice (Full Frame)==== 
| ACK > 
| 
| K----------- Voice Mini Frames------ > 
| <--- ---> 
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Media exchange 
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every 65536 ms) 


( 
( 
( 
(Note 4) 
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10. 


| <--- s || 
| <--- F ---> | 

&K----------- Voice Mini Frames------ > 
| | 
| ====HANGUP > | Either can hangup 
| < ACK | 
| | 


Note 1: There will be multiple DPREQ/DPREPs per call unless 
dialed number is 1 digit long. 

Note 2: Mini Frames carry the low 16 bits of the peer’s 
32-bit time-stamp. 

Note 3: Full Frames resync the 32-bit time-stamp when the 16 bit 
time-stamp overflows. 

Note 4: Each side has its own 32-bit time-stamp so each side needs 
to sync at 16-bit overflow. 


Security Considerations 


TAX is a binary protocol for setting up point-to-point call legs that 
include both media and signaling. As such, it is simpler to secure 
than other more general purpose VoIP protocols; however, security 
remains a difficult task and various aspects of the protocol must be 
examined to identify risks. 


IAX registration is an area that requires careful attention. 

Previous protocol versions supported cleartext passwords; this 
feature has been eliminated. The MD5 and RSA alternatives offer much 
higher security. Although not specified by the IAX protocol, some 
implementations limit the number of registrants per account to one. 

A subsequent registrant with the same credentials would overwrite the 
prior and receive the calls destined for that user. Theft of service 
is trivial once a malicious caller has the ability to authenticate. 
In addition, since distinct cause codes are returned to erroneous 
registration attempts, an attacker can distinguish between existent 
and nonexistent users in a registration system, thus resulting ina 
possible directory harvest attack. 


The IAX protocol protects against message replay by using a challenge 
response method. The IAX registrar or server challenges each call or 
registration with an arbitrary MD5 or RSA challenge. The response 
and subsequent authorization relies upon knowledge of a shared 
secret. Since the server typically chooses a challenges using a 
random-number-based technique, the challenge set is large, making 
replay highly unlikely. 
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Although operation in the following manner is not recommended, the 
TAX protocol does permit servers to forego the challenge process 
described above. This open approach is inherently insecure and does 
nothing to prevent unauthorized usage. 


Call Encryption in IAX starts by utilizing static keys. Once 
negotiated, the key may be changed for the remainder of the call. 
Once the initial key is compromised, all subsequent calls are subject 
to interception. A more secure implementation would update the key 
frequently and as early as practical during each call. 


The IAX protocol is also susceptible to eavesdropping. Call Detail, 
i.e., who is calling whom, is sent in unencrypted binary whether or 
not the call is to be encrypted. Without encryption, call content, 
i.e., audio and video, may be easily intercepted. However, this 
content is protected if the call is encrypted. 


Man-in-the-middle attacks are a threat to IAX if encryption is not 
used. This form of attack permits message insertion, deletion, and 
modification such that a call may be redirected or the audio or video 
replaced in either or both directions for the complete or any portion 
of a call. If encryption is used, the call is protected end to end. 
Note: an initial NEW message in an encrypted call is unencrypted and 
could be changed; however, this is limited to a denial-of-service 
(DoS) attack because subsequent messages containing the same address 
information are redelivered in an encrypted form. 


DoS attacks can take at least two forms in IAX. One is simply 
overloading the peers with bogus requests. A carefully implemented 
IAX peer would identify this situation and raise an alarm or take 
other protective action. 


Another form of DoS against an existing call is an engineered attack 
against an existing call. Injecting media, causing excess processing 
by inserting out-of-order packets, and sending commands such as 
hangup or transfer. These attacks require close monitoring of the 
binary channel to be successful as the message sequence numbers would 
need to be synchronized with the protocol exchange. 


Of course, providing lower-layer security with Datagram Transport 
Layer Security (DTLS) [RFC4347], or IPsec [RFC4301], would address 


many of these potential issues. 


Unicode [RFC3629] and stringprep [RFC3454] security considerations 
also apply. 
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11. 


I2. 


IANA Considerations 


In order to facilitate the orderly extension of the IAX protocol, 
several IANA registries have been created. These registry requests 
are found in [RFC5457]. In addition, the "iax" URI scheme has been 
registered; see Section 5. Also, IAX has been assigned a well-known 
UDP port number (4569). 


Implementation Notes 


The original IAX implementation was in Asterisk, the open-source PBX, 
but [wikipedia] lists thirteen other publicly available 
implementations at the time of this writing. Some of these 
implementations used draft versions of this specification. Many 
others were developed using the Asterisk source code as the only 
specification. While this approach is definitive, it is very 
difficult to determine the protocol's higher-level logic and optimize 
it for the particular programming language or application 
environment. Interoperability of these implementations cannot be 
guaranteed. 


Aside from the trials and tribulations of reverse engineering the 
Source code to create a new implementation, the key lessons learned 
involve the use of threads, support of international character sets, 
security, and improved controls to limit interference during DoS 
attacks. 


The current Asterisk implementation has a limited number of IAX 
worker threads and, as a result, its scalability is limited, but it 
can run on low end machines where threads may not be freely 
available. Improving the threading model will undoubtedly improve 
performance. 


Internationalization and localization are issues that were not 
originally addressed by most implementations. It was always on the 
IAX developers' road map, but never a priority. While creating this 
document, we formalized support for UTF-8 encoding to better support 
internationalization and localization. 


With regards to security, many IAX implementations permit cleartext 
authentication. This method is not secure and should not be used. 


Recently, some issues have been raised regarding server robustness 
when under a DoS attack.  IAX servers that support unauthenticated 
requests can receive the equivalent of a SYN attack. To mitigate the 
impact of these attacks, various controls to limit the number of 
unauthenticated calls and the number of calls per user may be added 
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to the implementation. Other approaches, such as transferring the 
call to another, more protected port or using IP rate limiting when 
excessive failures are detected, are also suggested. 


Lastly, given the open nature of the protocol and implementations, it 
is very easy to extend. This situation makes Postel's Robustness 
Principle, "Be conservative in what you do, be liberal in what you 
accept from others", essential to any successful IAX implementation. 
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